Good morning, everyone. I guess I go over here. There we go. All right, I came here to talk about certificates in Mac OS X and certificate management. And so this session covers the usage of certificates and the way certificates are used and as well as keys. And a lot of times people are talking about certificates. They actually mean certificates and keys.

The whole sum of things, certificates, keys, and trust management, et cetera, is often referred to as a public key infrastructure or PKI. So I'll be referring to it by that acronym if you may. So different kinds of applications use PKI for different things. The most common use is to identify a person or party on the other end of a connection and determine -- determine who they are and set up a secured or authenticated or encrypted transaction with that other party.

Some examples of applications that use PKI would be on Mac OS X today are Mail. Mail uses, since Panther, Mail has support for SMIME, which lets you send encrypted and signed email to people on both Macs and Windows and every other operating system out there that has SMIME support. Mail also uses PKI for its SSL support, which you would use if you were connecting to a secured IMAP server or a secure SMTP server.

So some of the things you'll learn. We'll start with the PKI review, and I'll try and explain a little bit, just a really high level view of what public key cryptography is and what certificates are. Then I'll go over our new PKI related APIs. We have a few. I mean, we had a lot of APIs already in Panther, so we haven't added a whole lot.

But we've had some requests for some new things, and we've listened to you guys, and we've added that. Then there's some improved and some new PKI views that we'll show you. We'll talk a little bit about keychain access and user bin security and what some of the new things have been going on with those are. And we'll talk about root certificates and how Mac OS X determines whether or not a root certificate is trusted.

And I'll explain why that's important later on. And something else we'll be talking about, which unfortunately this didn't make it into the discussion, is the fact that we're working very, very hard to get smart card support into Tiger. And there will be fully integrated smart card support in Tiger.

So, and smart cards will be just like key chains. So, as you, when we get to that portion, I'll go into a little more detail about that. And I'll also talk shortly about what it would take for, if any of you are CAs or representatives of CAs, to get your root certificates included into either new version of Mac OS X or software updates.

I have to get closer, I guess. There we go. So, here's the PKI review. So what is public key cryptography? I don't know. Raise your hands. How many of you need this explanation? Or is everyone here a security expert? So I'll do this kind of quick, since there's only a few people that don't really know.

So public key cryptography works by you generate a pair of keys, a public key and a private key. Now the public key can be shared with anyone out there and doesn't contain any secret information. The private key corresponds to a particular public key, and you need to keep that private key secret. The private key is kept secret by the owner of that key on his machine or on a smart card or some other token.

Public Keys can be used to verify signatures. So if someone signs something with a private key, you can verify what was signed with the public key. And private keys can be used to decrypt data that was encoded with a public key. So if someone else has your public key, they can send you an encrypted message that you and only you can decrypt.

But by itself, public/private keys are, it's a really cool technology, but the problem is how do you know who a particular public key belongs to? and I have to go back. Right. Well, the way we do that on Mac OS X, and there are other solutions out there, but the way most of the industry has adopted is X.509 certificates.

And what an X.509 certificate does is it binds a public key to other forms of identification. and in addition, it's certified by a third party. So it produces a binding of your public key to some attributes about the owner of that public/private key pair and there's some other third party that actually asserts that that binding is correct or valid.

Well, what's in a certificate? Well, obviously the public key because that's what we're trying to bind to this other information. Then there's a number of attributes. One attribute that's always there is the issuer. The issuer actually refers to the certificate that certifies this particular certificate or the authority that has issued this certificate.

Then there's a subject, which is a description of the owner of that certificate or the key in that certificate. Both the issuer and subject are X.500 names, which if you don't know what that means, it's basically like an LDAP distinguished name type of record. I mean, it's actually a superset of an LDAP name, but it's similar to that. So it'll have things like the common name and an organization, and you can add all kinds of different fields to it. And it's really up to the issuer of the certificate to decide which fields they want to certify in a certificate.

And then there's a validity period in a certificate, which tells you from when to when that certificate is valid. In addition, X.500 certificates as of version two or three, or two and three, can contain one or more extensions. Now, extensions are arbitrary things that can be added to certificates. Now, there's a number of extensions defined out there and a number that are commonly in use.

Some of them would be a key usage policy. There's an extension, or there's an extended key usage policy extension as well, which tells you, well, this certificate can only be used to sign things rather than to encrypt things. Or this can only be used for email, or this can only be used for a website, et cetera.

And there can be policy statements included in certificates which might contain a URL referring to a website telling you, you know, what it means, what the fact that this authority has issued this certificate really means, or what the guarantees are that they give you, et cetera. Extensions fall into two categories.

There's a flag on an extension. There are critical and non-critical extensions. Non-critical extensions you're allowed to ignore if an application is processing a certificate and it doesn't understand that extension. It's okay to ignore it. If an extension is marked critical, then you must understand what that extension means, or else you should just not use that certificate in your application.

There are very few extensions that are actually marked critical in certificates. Usually the ones that are are crucial to the usage of that cert. And then finally, there's a signature of all of the above information included in the cert. And the signature is using the private key of the issuer.

Now, since a certificate has an issuer, there's essentially a hierarchy. You can have a hierarchy from certificate issued by some other certificate, and that certificate in turn is issued by another certificate. The nice thing about certificates being signed is that they can't be tampered with. If you have a certificate, you can verify its validity, and you can verify the issuer certificate's validity, and you can keep going up this chain.

So, we call the certificates at the bottom "leaf certificates," and the certificates that sign "leaf certificates" "intermediate certificates." Now, eventually that chain has to end, and that happens when you get a certificate for which the issuer is the certificate itself. And we call that a "root certificate" or a "self-signed certificate." And the only way you can determine whether or not a root certificate is trusted is by prior arrangement.

So, in summary, here's an example of a cert issued to Ken issued by some other authority. There's no real limit on how long a chain can be, although there are extensions in certificates which can limit the length of a chain. So a root certificate could limit the length of a chain to two or three certificates or depending on what that certificate authority wants to allow. But so typically an application validating a certificate will follow the chain from the leaf certificate back to a root certificate.

So, root certificates are also known as certificate authorities. And some, there's a number of different certificate authorities that we ship. I think as of 10.3.4, there are about 84 certificate authorities in the file mentioned below, System Library Keychains X.509 Anchors. You can actually manually add certificates to that file by, if you have a root certificate on your desktop or somewhere in the finder, you double click it, it'll launch Keychain Access and Keychain Access will allow you to add it to the X.509 Anchors database.

So, if for example, you work at a university or some institution that has their own certificate authority that doesn't use one of the 84 that we already include, you could download that certificate authority certificate to that file. So, you can add that certificate to your machine and after verifying that it is the correct certificate, you could add it to your keychain on your system. And from then on, any app on Mac OS X will trust certificates signed by that authority.

So certificates are only half the story, of course. I sort of alluded to this earlier. Certificates contain the public key, but for you to be able to do something with a certificate, you also need a place to store the private key. Now certificates, because of the fact that they're signed and they don't contain any secret information, there's no real problem storing them.

You could store them anywhere. You could store them on an LDAP server, you could store them, you know, as files on your desktop, you could download them from a website, et cetera, because you can always verify their correctness and there's nothing in there that you need to keep secret from anyone else.

Now, if you take the certificate and its corresponding private key, where corresponding is basically the private key that belongs to the public key in the certificate, we refer to the combination of those two as an identity. And in our APIs, there's actually a sec identity ref object, which represents the combination of a certificate and a private key. Now, in Keychain Access, an identity looks like something like this. you'd have a private key and a certificate that are paired together.

Some examples of some applications and what they do. So Mail, like I said, uses the SMIME APIs for encrypted and signed mail. It uses SSL to receive mail from a secured IMAP server or from a secure SMTP server. And again, in Mail, you can actually view the certificates if there's something wrong with the connection, etc. It's delivered in Panther. I think the Mail team is actually working on some improvements. And with some of the stuff Ken is going to demo to you later, you'll actually see some of the new UI we have that will be integrated into Mail as well.

Secure Transport, something that's been around since OS 9, I think, or in some form since OS 9, is used both by Safari and Mail for SSL and TLS. It supports every variant of SSL, V1, V2, V3, TLS, and it auto-negotiates between all of them. Since the 10.3.3 update, we also support client-side authentication. And because Secure Transport supports it, then every app that uses Secure Transport actually gets this for free.

Now, CF Network uses Secure Transport under the hood, so guess what? Every app that uses CF Network also gets these features for free. And when we add Smart Card support, every app using CF Network or WebKit, which uses CF Network, will also get Smart Card support for free.

So, now I'll talk a little bit about the new APIs. There really only are two completely new APIs, and they are SecKeychainItemImport and SecKeychainItemExport. What they allow you to do is to import and export certificates and keys to and from key chains. and we support a variety of formats. Pretty much everything out there we could find that we thought would be needed by anyone is in there.

So we can export to raw open SSL with PEM, ASCII, Armour or without. Support PICSS7, PICSS12. You can even import and export SSH keys. So if you had an SSH key, you could import that to your keychain or store it on a smart card, take it to another machine and use that SSH key there. - Yeah.

and there's some additional formats that you can store either individual items and some of the formats allow you to store multiple items. The import function actually can auto detect the type of content that you're importing from. So if you're writing an application and you're trying to allow, you know, importing of arbitrary things, you can just call import with pretty much all wildcard parameters and it'll just figure out what the format of the input data is. Or if you want to specifically limit it to PQSS 12, you can do that.

So here's a little synopsis of what the calls look like. They're pretty basic. SecKeychainItemExport, you pass it an array of items, which are all keychain items, which could be either certificates or keys or some combination thereof. Then the format in which you want the items exported, which would be SSL or PKS 12 or whatnot.

Then there's some flags, which example of flag would be whether or not you want it base64 encoded or PEM armor encoded. If you're exporting keys, you pass a pointer to instruct with key params, which contains some additional details about what things you want to do with the keys. And then the last parameter is you get the result, which contains basically CFData containing the exported items.

Now, this may or may not work if you're exporting, let's say, keys from a smart card. If the smart card doesn't allow you to export the key, it won't work, obviously. But given that the permissions are correct, the export will work. Now, if you're exporting a key from a key chain, typically, because key chains have access control lists, the user will be prompted with some kind of dialogue asking him for permission to export that key.

Import looks pretty similar. It has a couple more parameters because it's a little bit more complicated. The first parameter is the data, which is again a CFData containing the blob of information you want to import. Then there's a file name parameter, which is optional, but that can be a hint if you don't know what the format is, but you've specified the file name.

The import function will use the extension of the file name to guess what the format might be. Then there's a format parameter, which is both input and output, which could be pqsf12 or ssl or whatever the format is that you think the data is in, and on successful completion, that will actually contain the format that the data really was. Then there's an item type, which is both input and output, so that could be a hint.

You could say, oh, this is a certificate or this is a key or I don't know. And on completion, you can say, oh, this is a key or I don't know. And on completion, you can say, oh, this is a key or I don't know. And on completion, you can say, oh, this is a key or I don't know. And on completion, you can say, oh, this is a key or I don't know.

And on completion, you can say, oh, this is a key or I don't know. And on completion, the item type will say, well, this was a certificate or this was actually a combination of multiple items or this was a single key. And then there's some flags. The flags can, again, be things like whether or not it's ASCII armored.

On import, you have this pointer to key params again if you're expecting to import keys. Things in there for import would be like what the permissions you'd want on those keys to be after they've been imported, etc. Then you can obviously specify keychain which to import the items to, and you can also optionally specify a output array in which it'll return the items that were imported.

So how do you import and export items? Well, on the Developer CD you have today, Keychain Access lets you do it. There's an import menu and there's an export menu in File. So you can just go to Keychain Access and do it right there. There's also a command line tool, User Bin Security, which has an import and an export command. And there's actually help built into User Bin Security and it's also a man page.

So, user bin security will let you do it. And then in addition to that, you could use the APIs that I just explained if these two options aren't good enough. There's documentation. I don't think there's documentation on the WWDR site yet, but there is explicit comments in the SECimportexpert.h header in the security framework. So if you want to take a look, that's on your CDs that you received yesterday or Monday.

So here's an example of how you would use the command line tool. So in terminal, if you wanted to export all the certificates from your login keychain in PEM format, for example, as a PK-SYS 7 log, you'd say security export, well, what it says there. So with that, I'd like Ken to come up and show you how to do the same thing in Keychain Access. And he'll show you some other things as well.

Thanks, Michael. Can we have the demo on screen? Thanks. I'd like to start by showing you some of the new additions that are in progress to the Keychain Access Utility. If you've had a chance to fire this up off of your Tiger preview, you'll notice it looks a little bit different than the one that's in 10.3. One of the first things you might notice is there are now categories over here on the left-hand side.

So instead of looking at all the items in my keychain, I can just look at my passwords or just my certificates When you've been using the keychain for a while, and I've been using Mail, and I've built up an awful lot of certificates here, and it's kind of hard to find them.

So we've also added a search feature. So I can look for, if I'm going to send mail to Murph, I can just type in Murph's name here. And there's Murph's cert. And I can look at his cert. Maybe I want to see where all the Thought certs are. So I'll type in "Thought." And you'll notice that it's returning the certificates that it finds across all the keychains. So I have a copy here in one of my keychains, and I have the other ones that are in the Anchors database.

So let me look for stuff that contains my name here. And I got some of my stuff. I have a certificate here, and I have my private key. And as Michael pointed out, those combination of things make up my PKI identity. So I can take advantage of that new API that he talked about, setKeychainItemExport, just by going to the Export menu here in Keychain Access. So I'll select that.

And let's make a file called Ken's PKI. And I have some options here. I can export things as a cert, as a PAM armor. What I want when I'm exporting my private key is to put it in a P12 file or personal information exchange, which is actually encrypted. So I'll go ahead and save that. It asks me for a password to actually encrypt that file, so I'll give it a super secure password here. here.

Go ahead and say OK. So we look out here and it's created a P12 file. And that's a standard format for information exchange that could be read by something like Mozilla. It can be read on other platforms. I can copy this over to my Windows box and import it there.

Let's double click it and import it into a different keychain here. So when I double click it, it brings up Keychain Access and asks me where I want to add it. So let me add it to my login keychain. And of course, I have to enter that password again, which decrypts the file.

I'll go back over here to the login keychain and I see that it's added those things from the P12 file. I can look at it and sure enough, it's my certificate and my key. So, let me tell you a little bit about this certificate view that Keychain Access is showing you. It's a Cocoa view and it's reusable. It's called SF Certificate View.

Now you have some flexibility with this view. Keychain Access here is just showing you kind of a summary view with the essential information about the certificate, the name and who issued it. But I can also open it up and get a different instance of that SF certificate view that shows me a lot more information, shows me all the things that are inside the cert.

And I can choose to disclose or hide the details and some of the trust settings. All these things are controlled programmatically, so your application can use this view and decide to show just a brief summary view or the entire contents of a certificate. So let me show you another example of how you might use that view in an application.

This is the mini browser, which is a little sample application that comes with WebKit to show you and demonstrate WebKit. Because it's WebKit, it is built on top, as Michael said, built on top of CF network and secure transport. So you get all these things for free, like HTTPS. I can go to a site that uses SSL, and And this all just works with WebKit.

Let me go to the store here and see if that will work. Unfortunately, the little button I added is not showing up. So I think that the demo gods are not smiling on me today. Let me try going to a different site here. which is the University of Washington has a web page and not to single them out in particular, but they're an example of a site whose root certificate is not part of the default set that is in the X.509 anchors file and is trusted by default with Mac OS X. So normally you would have to go and add that certificate out of band. So we have a new view, a PKI view called SF Certificate Trust Panel.

And what I've done is I've gotten the certificates and I've put up this panel with some text that I supplied and it's basically asking me for permission because it could not verify the certificate chain. And this panel has some features. I can go ahead and disclose the certificates that are involved. And I look at it and I see, yes, this is a site at the University of Washington and it's signed by their root certificate.

We've got an option here. As I said, normally the way that you would go and trust a certificate is out of band by having to add the certificate into X.509 Anchors. This isn't quite working yet, but we're working on a way to actually bring that process in band a little bit for the user, so they can just say, "Go ahead and remember that I said to trust this." So I can click "Continue," and it goes ahead and loads that page.

So let me show you just real quickly what it took to implement that in this mini browser. I just went and added a function or a method here to the sample document called Evaluate Trust. And the first thing Evaluate Trust does is it makes a SecTrust object by calling SecTrust create with certificates. So I take those server certs that I got back from the making the connection and I make a SecTrust object which kind of encapsulates all of that information. The policy that I'm interested in which is SSL.

And then the next thing I do is evaluate it by calling SecTrust Evaluate. And that will go off, do all of the searching for the root cert, any other certs in the chain that it can find, does the cryptographic evaluation, and returns a result. And that results the interesting thing. There are a number of them. I can have explicitly denied or explicitly allowed the certificate in advance.

But the interesting error that returns is a recoverable trust failure. And those are cases where, for example, the root certificate is expired or it's not present in the X.Anchors database. But this is something that you can go ahead and override. You can ask the user what to do.

So my method here asks the user what to do. It puts up a message about mini browser being unable to verify. And then it creates an instance of this view, SF certificate trust panel. I set up the title of a button. You have complete control over the message and the titles of the buttons that appear.

And then I just put up a sheet on the window asking the user what to do with a selector that will get called when they dismiss it that will go ahead and either load the page or not load the page. And that's it. That's all the code I had to add to get that working. So if I could have the other slides back for a moment. Could we switch? Thanks. I probably have to move over here to make it work.

Yep. So there are three views that I showed you, SF certificate view being the base one, the kind of building block one, and then certificate panel that's built on top of that. The thing we just looked at was the SF certificate trust panel, which lets the user make a decision about trust. One that I did not show you was the choose identity panel, which lets you pick from multiple PKI identities. And I'll get into that in a minute.

All of these are COCA classes that have been available since 10.3, but we're adding new functions, adding methods, and improving the functionality, and also improving the look of them so that they have features like progressive disclosure, where you're not pummeling the user with all the information in a certificate right away, but it's there if they need to look at it.

Here's an example of the one in the front there is the SS Certificate Trust Panel. And this is just a sample use in Safari where it would put up a message. You'd have the option to show the certificates involved and then to continue with the operation or to cancel.

So, SF Certificate View is pretty flexible. You can just show a summary view with the basic information, the name of the cert. You can add programmatically little turn down triangles that progressively show you more and more detail. And another thing that I missed, but you can actually grab hold of that cert in the view and directly export it. You can drag it to the finder to directly export a certificate file. You can drag it to a mail message to export either in PAM Armor or not the certificate. And it gives you a lot of flexibility. That's all built into the view.

The SF Certificate Panel is used in cases where you just want to show certificates without necessarily needing the user to make a decision. So it's for informational purposes once the operation has taken place. For example, maybe you've got a website like we saw there where the operation was successful, the certificate chain verified, but you actually want to be able to see that and know what certificate it was.

So you can choose to display just one certificate or the entire chain, and you can also add certificates that aren't part of the chain when you're showing that view. There is a standalone interface to that panel, or you can have a sheet interface as we saw in the demo.

Now the SF Certificate Trust Panel is the one that you'll want to use when you need to make a trust decision. You don't have enough information, the certificate chain was not necessarily valid or maybe one of the certificates expired. There was some problem with it and you want to ask the user what to do.

So this panel does all of the hard work and the heavy lifting for you as far as showing you the certificates and giving you the tools to be able to ask the user what to do. Again, like the previous panel, it comes in a standalone panel or in a sheet interface version. And you have complete control over what text shows up and what the buttons look like.

The SF Choose Identity Panel is one that I didn't show, but very similar to those in that if you need to select from multiple identities, and this is happening more and more. For example, users have maybe a free email certificate, and then the university or the company or some institution will also issue them a certificate. And so they could be signing or encrypting things with, they have a choice of keys and certificates to do that with.

So we provide you a panel that you can bring up and to display the available identities and to ask the user to pick one, and then it returns the identity that they chose. Again, with progressive disclosure, so you see the names of the identities, and then the user can choose to show all the details or some of them.

Again, it's a standalone version or a sheet, and you have control over what the buttons look like. So with that, I'd like to ask Michael to come back up, and he will tell you a little bit more about the X.509 anchors and how they're trusted. Thank you, Ken.

So I talked a little earlier about there's the X.509 anchors file on Mac OS X which contains all the root certificates that are trusted by the system. We've actually started doing some software updates to that file, and we've been very careful when we did the software update to make sure we didn't just overwrite the anchors database, but we add the new anchors that we've gotten approval for to that file without blowing away any anchors that you might have added yourself. And that's also true when you upgrade from Panther to Tiger, it'll preserve the anchors database on your system now, which wasn't true going from Jaguar to Panther.

So we'd really like you to talk to us if you're a CA or if you somehow want to get your research into the system about getting them added to Mac OS X. And the person to talk to would be Craig Keithley, and I'll put his contact information up at the end of the session. One thing I forgot to mention earlier on in the session was that Mail uses the SMIME APIs-- sorry, the SMIME SPIs.

And the reason that the SMIME stuff is still SPI is because we really haven't gotten a lot of feedback from developers asking us to make SMIME an API. Now, if you're a developer of a Mail client and you want to see SMIME become an API, I encourage you to bring that information to the feedback forum.

So next up, smart cards, what I promised in the beginning. Smart card support in OS X. There's some good news and there's some bad news. The good news is we're actually going to be doing something revolutionary here. Compared to any other platform, the smart card support that will be in OS X will be horizontal smart card support. It will be across the entire OS, supported for-- you can use the same smart card to log in, to authorize access to certain settings in system preference, services, use it in mail, use it in Safari.

You can use it for your screen saver. It could be used in a server to store server keys or certificates on. Any apps using CDSA or CDSA-based APIs, meaning the keychain APIs, the secure transport APIs, or any higher level APIs, will benefit from this. And we'll have single sign-on with the smart card. So you insert the smart card. Enter your PIN once to log in.

And you won't have to re-enter your PIN every time you do something with the card, unless you choose to. Because you'll actually be able to set access control list entries on that card, which the security architecture will actually fan out access to that card to multiple applications and gate access to it using access control lists. Previously on Mac OS X, we've only really had a few select, vertical smart card solutions that were based on PCSC.

Our new architecture is still based on PCSC, but the difference is we're actually sharing access to the card. PCSC didn't give you any abstraction that let you support multiple cards. It just abstracted basically the reader. So you'd plug in a USB reader, and PCSC would deal with loading a driver for that.

But if you had three different cards, you'd have to have three different libraries in your application to talk to those three cards. That's all over. That'll all be over when Tiger ships. So here's an overview of what the architecture looks like. And on the top, the green box there, is the applications.

I guess we don't get a cursor here, so well. The green box on the top are your applications, which are either sitting on top of the Sec APIs or Secure Transport or CFNet Perk or WebKit or whatnot, which in turn is layered on top of CDSA, which is CSSM is the API part of CDSA.

That sits on top of a new plug-in module that's going to be in Tiger, which is the SD CSPDL. SD stands for Security D. Security D is what used to be called Security Server in Panther. We've renamed it to Security D in Tiger. So the SD CSPDL actually represents a CSP, which stands for Cryptographic Service Provider, and DL, which is a data store library module.

You can think of the CSP part as anything to do with cryptography. Encryption, decryption, signing, verify, all that goes through the CSP part. The DL part is anything to do with finding items or records or modifying items or records. So searching for a certificate or a key. That happens through the DL interface. Using that key to actually do something goes through the CSP interface.

So if your app was actually written directly to CSSM, which I doubt very few of your applications will be, I think, you'll have to actually modify your app to be aware of the new Smart Card CSPDL. If your app is using any of the higher level APIs, it won't require any changes.

Then SecurityD actually talks to PCSCD. Now the only communication really between SecurityD and PCSCD is that SecurityD watches for token insertion events. PCSCD tracks the readers on your system, so if you plug in a USB reader, it'll notify SecurityD of that and SecurityD will say, "Okay, fine, whatever." When you actually insert a smart card into one of those readers, PCSCD will notify SecurityD.

When that happens, SecurityD will try and get a code off the smart card to try and identify that card. Based on that, it'll narrow down to a selection of one or more different TokenD instances that are on the system. So each TokenD that is on the system can be seen as a driver for a particular token, and token being a smart card.

So each TokenD supports a particular class of tokens. So you could have one for card for manufacturing. One for manufacturer A, another one for card for manufacturer B, etc. So SecurityD will then launch the ones that are candidates for that card and ask them to tell SecurityD whether or not they support that particular card that the user just inserted. And when it finds the one that actually supports the card, it'll keep that loaded and TokenD will establish a session to the card.

So here would be an example of a third-party token D. So you might have noticed you haven't seen PKSS 11 anywhere in this architecture. Well, that's because PKSS 11 is really not an abstraction layer. It's more a library layer to talk to one particular card. So if you had a PKSS 11 library to talk to your brand of card already, it would take very little work.

Basically, the part in your token D would be the only code you have to write because you already had the PKSS 11 driver that uses the PCSC framework on Mac OS X. And you just have to write a little bit of glue code to transition from the token D interface to security D down to PKSS 11. Those two interfaces are actually fairly similar. The security token D is the one that's going to be the most important part of the process. So the security token D interface is somewhat closer to CDSA than PKSS 11, but they have very similar sets of calls.

And one of the things we're looking at doing in the future is actually making the Your Token D box be part of Security Token D, meaning that if you already had a PQS 11 driver, you might not have to write any code to provide a Token D. Although, there'll probably be a little bit still, because the auto discovery that we're doing is not something PQS 11 supports.

So here's the bad news, or at least potential bad news. There are a couple of existing smart card solutions out there. Now, all those existing smart card solutions were vertical solutions in that you had one or two applications that knew how to load a driver for a particular card and talk to that particular card or cards.

The problem is with the new architecture, because we're doing single sign-on, as soon as we ship a token D that supports that card, it'll automatically get loaded when the card's inserted and it'll open a session to the card. Now, if the card is single session, that means that your vertical app will not be able to coexist with the token D on the system because the card doesn't support two. Even though PCSC will let you do it, the card won't support two apps directly accessing it.

Apps written to the higher level APIs will. Because the whole reason we're doing this architecture is to have cards that can only do one session still be capable of being shared between multiple applications at the same time. If this is really, really a big problem for you, we'd really like to hear this at the feedback forum. Because we have some ideas of things we can do to potentially get around this, but you would lose a single sign-on when you launch your vertical app, basically.

But obviously the best thing to do is to transition these apps to the new architecture in Tiger. Because then you'd get support in Mail and Safari and everything and not just in that one app. So, in particular, the CAC cards and other cards supported by Muscle will be supported natively in Tiger, so they'll have this problem because I don't think any of those cards are multi-session.

So, and again, talk to us about adding support for other types of cards into OS X because, I mean, wouldn't it be cool if you could use Safari to do your client side off with, you know, your custom card that you're using and mail to send secure mail and log in and use your screen saver, et cetera.

So, for more information and if you want to talk to us, please contact Craig Keithley. And with that, I'd like to bring Craig on stage. And he's the Security and I/O Technology Evangelist.