Well, good morning, everyone. Welcome to the ultimate session of WWDC 2006 on X.509 certificates. Thanks for coming. Thanks for making it this far. It's been quite a week. My name is Ken McLeod. I work in the data security group, which is part of CoreOS at Apple. And today's session is all about certificates, and we'll kind of be focusing on digital identities, using certificates as your identity, and how you get an identity, how you find one, and how you use one. Another important thing we'll be covering is the idea of a preferred identity or preferred certificate, and how you figure out what the user's preferred cert is in the case where they have more than one.

And finally, a very big one here. There are big changes in Leopard on how certificates are actually trusted. So be sure to stick around for that one. I'll be covering a little bit about the built-in facilities and functions in Mac OS X for actually doing things with identities, signing, encryption, and authentication. And then we'll round this out just by briefly talking about some of the new functionality that's in Common Crypto.

So first off, what is an identity? This is a term that's like key or some of the other words that are thrown around that get overloaded a lot. And when we talk about an identity in this session, in the kind of public key infrastructure sense of an identity, an identity is just a certificate and a private key, the combination of those two things.

The private key is something that the user has, something that you have, and the certificate half of the identity is issued to you to identify you as the holder of that key. And it also has a function of being able to limit or set out what the key is used for.

Identities are contained in keychains. Now, a keychain, as you probably know, is the standard repository on Mac OS X for things of a secret nature that you want to keep secret, like your keys and cryptographic material. So you can store these in a standard file-based keychain. You can store them in a token, like a smart card, and if that token has a token D module that supports it. We had sessions earlier in the week that if you didn't manage to catch them, you can check out on the DVDs afterwards.

But they're available in tokens. They're also, if you have a LDAP directory, you can put the certificate portion of the identity out there as part of a user's record. If you have the user certificate or the user SMI certificate attributes of a user record, identities can be stored there.

This is kind of an important idea, and I'll come back to it again in this talk. I'm one user, but I can have more than one identity. I can have different names that I use. I can have different email addresses. The obvious example is I have a different identity for my work stuff than I do for stuff that's personal and stuff that's at home, and different email addresses for those.

But I could also have the same exact name and same exact email address, but issued from different authorities. So work can issue me two different certificates, or I can get one from an outside certificate authority. And I can also have different identities that look the same in every way, except they allow me to do different things. So one identity might let me sign my email, and another one might let me log in or encrypt something.

How do I get an identity and establish myself with my digital identity? Well, identities come from what's called a certificate authority. And at the very fundamental sense of a certificate authority, a certificate authority is a special kind of certificate that's allowed to sign other certificates. So it issues certs from there. But there's a lot more to being a certificate authority than just having that kind of cert. You need to keep track of all the certificates that you issue. And there's some, you know, policies and things to follow and things to be aware of there.

For example, every certificate you issue as a certificate authority has to have a different serial number. And so you need some way of keeping track of that. So there's generally two ways to go about this. You can either go to one of the traditional certificate authorities like VeriSign or, you know, any of the number--numerous others and request a certificate yourself. But you can also create one. And you can do that quite easily on Mac OS X. And I'll get into that and show you how So first let's cover how you normally do this with a traditional certificate authority. We have a user, Bob.

He's the typical sample user. And Bob wants to get a digital identity. So he goes to the certificate authority's website with his browser. And there's a little bit of an arcane HTML tag that is on the certificate authority's web page that lets the browser know, hey, you need to generate a key pair for Bob here on his computer. And so the browser goes and does that.

And then it bundles up the public component of that key pair into something called a certificate signing request. And that CSR gets sent off with the public key, the thing that doesn't need to be kept secret, off to the certificate authority. And the certificate authority takes its special CACERT and signs that request or issues a certificate to that public key for Bob. And hopefully it also checks out the CSR and makes sure that Bob is who he says he is.

Usually what happens is they just check to see that Bob has paid. At the end of this process, the CA issues the CERT to Bob. Bob can either pull it down by going to the web page or he can get it through email. That's often done. And it ends up on Bob's computer. And now Bob has the certificate and the private key. And to gather the combination of those two things is his identity. Kennedy.

There's an alternate method that's sometimes used. We see this done in enterprise and government kind of installations where Bob doesn't start this process. The authority actually generates the key pair and issues the certificate to the end user. And typically the way this is done is either with a token, where the key is actually on the token, or bundled up in what's called a PKCS12 file, which is the standard kind of container for secret information like keys and certificates.

So Bob can take that container and import it to his computer, and then he has his identity there. We don't usually recommend this way because Bob doesn't have control of his private key. It's held onto by the authority, but if the situation requires it, you can set things up that way. A better way to do it, of course, is to issue... a token like a smart card where the private key never leaves that token.

So, like I just finished saying, the standard way to move an identity, if you already have one, is in the form of a PKCS12 file. We fully support importing those. We can also import separately if you have the certificate or the private key. Those can be imported separately. They don't have to be together. The way to do this is, for an end user, using keychain access. It's in the utilities folder. They can choose the import from the menu, or they can just double-click a PKCS12 file. And it prompts them to add it.

There's a couple other options for getting your identity in. You can use the user bin security tool with the import command. And that allows you to import from a P12 file. You can also use the underlying API, which is set keychain item import. Now, that's been there in Tiger, and has a variety of options in the parameter list for specifying what kind of thing you're importing. So, you can import a P12 container.

If you have, for example, SSH keys, someone was asking me about, you can import those. If you have them in OpenSSL format, you can import those. So that's the existing identity part of things. But what if I want to set up my own certificate authority and do this process myself? Well, Mac OS X lets you.

There's three steps to it. And this is just a broad, general overview. You start by defining a certificate authority, your special CA certificate. You'll need some policies in place, as I mentioned, for tracking the certificates you issue from that. But then you can issue either with that route, or you can issue a special set of intermediate certs that will issue certificates from that as well.

And the last point is a problem that a number of people have had up to now. And that's the question of how do you get that root certificate distributed to your users in a trusted way? How can they trust the certificate that is issuing identities? So we'll go over all of that.

On Mac OS X, there's essentially two ways to go. We ship OpenSSL, and the OpenSSL command has a set of X.509 functions that allow you to set up a certificate authority. Now, if any of you have actually ever done this, you know it's not something you can do in an hour or so. It's got a little bit of a learning curve, because there's a number of configuration options that you have to set up and config files to set up the various extensions that you need in your certificates that you're issuing.

In Mac OS X, we have a much easier way of doing this, and it's called Certificate Assistant. Now, Certificate Assistant has been in there since Tiger, and it's been kind of hidden away, because it's under a menu item in Keychain Access. You have to kind of go looking for it, but it is there, and it provides a real simplified way of walking you through the process of setting up a certificate authority.

So it kind of looks like the panel there in the picture, just a series of questions that it will ask you step by step to fill out information that it needs to create the authority, and then subsequently to issue certificates from that authority. Now, Certificate Assistant will allow you to directly issue certificates on a machine, but it's also much more useful in an organizational setup to issue certs via email.

And so what that allows you to do is take requests from users. And remember a few slides ago, we talked about that request where a user in their browser will send you a CSR. So Certificate Assistant can take that CSR and process it and actually walk you through issuing a certificate to your user.

You can use Certificate Assistant to request a certificate from other traditional authorities, perhaps a higher-up certificate authority in your own organization. It will allow you to be a sub-CA as one example. And then there's some built-in utilities in Certificate Assistant that lets you look at certificates and evaluate them for trustworthiness.

In Leopard, there's two new features to certificate assistant. The first one is something called invitations. And an invitation is essentially just an email that is a way of allowing you to introduce the fact that you're setting up a certificate authority, and a way for that user to trust the root certificate that you've created.

And it's a bootstrapping process that involves, if you have an existing source of trust, if you're already signing emails, and you have a certificate that is on the user's machines, and they can see that the email comes from you and is signed, the email can include the root certificate, and the process of trust is kind of bootstrapped that way.

The other thing in Leopard that Certificate Assistant can do is generate a website for you automatically. So it can set this up, and it's a place for your users to go and click a button and say, "I want a cert from your certificate authority," and that process is taken care of automatically.

So since the word management was in this session title, I would be very remiss if I didn't talk about the entire lifecycle of the certificate. So we made it easy to create them, and that's all fully supported. But the other thing that you'll have to do in the lifecycle of a cert very often is to revoke it.

For example, if an employee leaves your company or if the certificate has been compromised in some way, you need a way to do that. The two mechanisms for revocation, the standard mechanisms, are certificate revocation lists and OCSP, or the Online Certificate Status Protocol. So first, the CRLs. We have a tool in the system, User Bin CRL Refresh.

And its purpose in life is to go out, and whenever it sees a certificate that it needs to evaluate, and that certificate has information about where to go to get that CRL, it will go out and cache those for as long as the CRL says that that's allowable, and have that and manage that on the system for you.

So when system processes that work with certificates under the hood call SecTrust Evaluate in order to determine whether or not the certificate is trusted, it takes into account the CRL, if that's appropriate, and determines whether to trust it based on whether it's been revoked. And that kind of gets messy. So we're talking about revoking, say, 80,000 certificates, because that's an awfully big list of things to download. So OCSP kind of is an alternative to that, that lets you go out, talk to the server, and ask it about one particular certificate.

Again, the location of that server is something that's specified in the certificate when you issue it. So we have a tool, user has been OCSPD, that you may see running after a certificate evaluation has taken place. And its purpose in life is to go out and ask that OCSP server, is the certificate still valid? In terms of setting up a CRL list, there's currently no way on Mac OS X to do that. Other third parties provide ways of doing that.

We know it's an important area, and we certainly have it on our radar to look at, but can't promise anything in the Leopard timeframe. In OCSP land, you can use OpenSSL in server mode to run an OCSP server yourself. Again, there's no other support beyond that in terms of being the server portion of that.

So now let's talk about how you find an identity. When you need to use an identity, there's a lot of considerations. The obvious ones you think of, well, you know, I need my identity, I'll look it up by name. Or I need something that I'm going to use for email, so I'll look up the identity by the email address.

But there's quite a few other constraints beyond that that typically come into play. And an obvious one is in TLS or SSL authentication, the server may be set up so that it only accepts certain identities that are issued by, for example, its own infrastructure and its own certificate authority.

There's also usage considerations. I may need an identity that can only do signing, and I have to ignore the encryption ones. The policy may require that I need an identity that allows me to do authentication. So these are all considerations, and of course, last but not least, the user may have a preference.

If more than one certificate is possible to use, the user may want to pick one. Now, it's really not good behavior to just blindly find the first identity that matches and use that. Now, having said that, Apple actually does that in some places, and we know it's wrong, and we're fixing it. It's a bug.

So when you're looking up an identity, the primary API that you're going to use is SecIdentitySearchCreate. That sets up a search for an identity. And it's an iterative API, which means you get one back at a time. If you want the next one, you call copyNext again, and it gives you back the next one that matches.

The unfortunate thing about this API is that it has a limitation that you can only look up identities by a key usage. So you often get more than one that match, and if we remember back to the last slide, there's a lot of other considerations. You need to look at the issuer, you need to look at the name, all these things have to match. So it's a little bit limited in that respect, but you deal with it generally by asking the user once to pick, because the user usually knows what's best.

In Leopard, we're trying to address this problem for you. We have an API that we're working on, SecIdentitySearchCreateWithAttributes. And so all of those attributes that you actually need to make an intelligent search for that identity that you need, you can pass to that API, and it kind of gets you out of the business of having to do the post-filtering on the identities afterwards. And SecItemCopyMatching is another new API.

It's the API we're working on for Leopard. And that will give you back all of the identities at once. Instead of being iterative, you can get them all back in an array. Now, why would you want to do that? Well, the obvious use for that is you need to ask the user which one you'd like to present them a list of all of the identities at once. So that's it.

So the user wants to have a way of picking an identity, and you need to have that identity preference remembered. And what an identity preference is, or a certificate preference, is just a mapping. It maps a particular certificate to a particular use. And the use is specified by a name, which can be either like a URI, if I'm going to a particular website, or it can be my email address if I'm using the certificate for SMIME. And it's mapped also to the key usage. So, for example, signing or encryption.

So these certificate preference items are just standard keychain items. They're stored in the keychain, and they're actually in use. You may have seen these already in Tiger, because encrypted iChat will store an identity preference item in your keychain that points to the certificate to use for iChat. And likewise, Safari, when it's using SSL client-side authentication, will create one of these items for the website you're visiting.

The thing about having them in the keychain is that you automatically get syncing between machines, so you don't have to worry about that. The actual contents of the identity preference item, the attributes of the item, are still kind of in flux, so don't go mucking around with them directly. Use the APIs that I'm going to talk about here when you need to work with those preference items. And here are the APIs.

When you're looking for whether or not a user has a preference for an identity, you'll call secIdentityCopyPreference. And this is new for Leopard. secIdentityCopyPreference takes a given name or URI and a key usage, those things that were mapped, as we saw earlier, to the certificate. And if the user has set the preference, you'll get back the preferred identity. If they haven't set one, it returns nil. The converse of this, of course... is secIdentitySetPreference. So when a user actually does specify an identity, you can call this. It will set the preference, which will then be picked up later on.

If you're looking for someone else's preferred certificate, there's a separate API to call. That's sex certificate copy preference. Now, how do you know what someone else's preference is? Well, typically, when you get an email from them, it's part of the CMS message, the signed message, that includes their certificate.

And of course, you've seen their certificate show up in your key chain, but you never had a way until now to actually find out which one the user prefers to use. So this is the API to call to find that out. And of course, it has a converse as well, which is sex certificate set preference, which allows you to set that preference.

So this slide here is the single most important slide, I think, of the entire talk. So be sure, if you take away nothing else from the session, pay attention to this. In the world of Tiger, up to now, there's been a single source of trust for certificates. And that source is a special keychain file, X.509 anchors.

You've all seen it if you looked at keychain access. That's kind of a standard system-provided list of the certificates that are trusted. In order to get any new certificates trusted, for example, your own organization's root CA cert, you have to add that to the X.509 Anchors database. And in order to do that, you have to be an administrator on Tiger.

But not anymore. In Leopard, X.509 Anchors is still there, but it's deprecated. It's no longer the source of trust, and we recommend that you don't touch it. It's just there to look at. If you're going to be providing new routes on the system, we recommend that they go into the system keychain instead.

Apple will still be shipping a set of root certificates that are trusted. That'll go in system root certificates instead of X.509 anchors. And the idea behind system root certificates instead of X.509 anchors, why the name change? Well, this is an immutable set of certs. This can get shipped with the operating system. This can be updated with software updates without any fear of trampling over your trust settings or roots you've added.

But it's kind of the base level. It's the stock level of trust, and it can be overridden by an administrator. So at the administrator level, they can provide a set of roots and a set of trust settings that say these are also trusted, or they're trusted instead, or I don't want to trust some of the certs that Apple has provided.

And finally, a user can specify what routes they want to trust. They can specify, as well as routes, certificates further down the hierarchy. For example, I don't necessarily want to trust a big certificate authority's certificate that's issuing thousands of certs to who knows who. I would like to trust the actual certificate that I know to be valid without trusting the rest of them.

So all of that is permitted at the user level. With one caveat, the administrator in a secure environment can actually turn that off, and so there's only a system and an admin level of trust without taking into account the user's level. But by default, users have complete control over whether or not they trust things.

So let's say you're a certificate authority. You've used Certificate Assistant to set up a root certificate, and you're issuing certificates. And you want other people to trust your root. Well, that's asking a lot. It implies a lot of responsibility on your part. Like I said before, you have to have policies in place to control who you're issuing certificates to and know how to review them. You can't provoke them if necessary.

Especially important is you have to really secure your private key, the one that's issuing other certificates. Because if somebody else gets that, they can obviously issue rogue certificates, and it looks like they're trusted. Well, you need to take all these things into consideration. But of course, you don't have to root, or you don't have to set the level of trust at the root anymore in Leopard.

As I said, you can just trust a particular certificate, and you can't just set the level of trust at the root anymore in Leopard. So you can't have a certificate that you're interested in trusting without the rest of the hierarchy. I'll show you how that works in a little bit. We'll have a demo.

Now there's obviously some big implications here for people that are setting up machines and organizations. Right now, you're probably writing scripts or installers that add your root certificate to X.509 anchors, because that's the standard way to trust it. So you'll still need to do that if you're supporting Tiger and the earlier world. On 10.5, that's not going to be enough.

You'll also need to specify that the root certificate you're adding is trusted. Well, how do you do that? The easy way is to use a new command in user bin security called addTrustedCert. And if you're calling this function as root, you just pass it the cert, and it adds it, and it's trusted. Done. You can also call this as the user, and it will require authentication in order to make that change.

Again, we'll see that in a minute. So how does this happen typically in workflow? Well, if you have an untrusted certificate, the first time something that needs to use that certificate encounters it, and it sees that it's not previously trusted, it's going to need to ask and make a trust decision. If you're a user, you can trust just that. You can trust that certificate for that particular use and for that user.

If you're an admin user, you can extend that a bit. You can trust the certificate for all users. There's a variety of things that you can only trust it for particular use, let's say. I only want this trusted for signing operations and never for encryption. All that level of control is available.

Now, you can control that by editing those settings in Keychain Access. You're probably familiar with that view on the right there of the certificate. And all of those pop-ups now to let you set trust are actually hooked in, and they're part of the system's trust evaluation. You can use, as I mentioned, the security tool and add trusted cert to do that explicitly, kind of out of band, if you need to set that up.

The function that underlies all of that is set trust settings. Set trust settings is extremely flexible. You can look at the header. It's actually not on the slide, but it's in trust settings in the security framework. When you make this call, obviously, it requires authentication of some sort, because otherwise you could go in and trust anything you wanted to. So, at the very least, you're going to need, as a user, to enter your password here to change anything. anything.

But you get to do this as the user. It doesn't require the admin to come over, unless, of course, as I mentioned, you're in a controlled environment and you need to disable that and only have the administrator be able to change those. And the way to do that is with the security tool again. There is a user trust settings enable command that lets you toggle that on and off.

So I need to talk a little bit about user trust and trust settings. They sound the same, but they're quite different. User trust is something that has been around for at least two releases now, since Panther, in the sec-trust.h header. And this was a way of letting you set kind of an advisory preference as to, as a user, I don't trust this. I always trust it. I never want to trust it.

The problem, though, with that API is that it was only advisory. It was unsecured, so it didn't require a password to change that. And so typically, the calls that are made when you're using certificates in the system end up calling sec-trust-evaluate. And sec-trust-evaluate did not take that setting into account because it was unsecured.

Now, there are certain applications on the system that went ahead and looked at that. And used it as a supplemental preference. For example, I think VPN client is an example of an application that did that. Safari is an application that did not do that. So you probably noticed that even though you said, always trust this, you keep getting dialogues in Safari. Well, that's changed with set-trust-settings.

Because set-trust-settings is a secured preference and requires authentication to change, sec-trust-evaluate now takes that into account. And we'll show a demo in a minute. That lets you see how that works. If you're still calling set-user-trust, the old API, it's now just a shim. And it's calling through to the new API. So you'll automatically get the behavior of the new API on Leopard.

And finally, when we're talking about trust settings, you can spend a lot of time setting up a machine just the way you like it with, you know, I trust these, and I don't trust these, and I want to trust this for signing, and I don't want to trust it for anything else.

Ken McLeod You know, once you've gone to all that work and set up a machine, you want a way of replicating that, and there is an API that will take a particular domain, for example, all my user trust settings, and put them into a blob, a nice CFDataRef that I can take to another system and replicate those trust settings elsewhere. Ken McLeod Now, of course, like the other APIs, this requires authentication, because you wouldn't want just anyone going along and doing that to you.

Ken McLeod The converse of this, of course, is import external data. Ken McLeod You can import your own data, and then you can import your own data into a specific domain, and then have your trust settings set up again. Ken McLeod So with that, let me show you a quick demo of this.

Okay, so the first thing I'll do is fire up Safari. And because the network was acting up on me, I decided to set up my own web server here on my local machine. So I've got Apache running. This is just a standard kind of, you know, SSL requiring Apache installation here. I'm running it on local host. So I'll go there. Ken McLeod And the first thing I see is a dialogue that you have all seen before.

It can't verify the identity of this website that I'm going to. Well, why not? We can inspect that. And in fact, you know, I just set up my own root cert here on this machine, and the system doesn't trust it, and nor should it. And I issued myself a cert to local host.

On Tiger, and previously, if you didn't want to see this dialogue again, there was only one way to go. You had to take the root certificate. test CA or whatever your company's root certificate was, and you had to import that into X.509 Anchors as an administrator. So if you weren't an admin user, you had to get the admin to do this for you.

But with trust settings, you I can decide to only trust that particular certificate that was issued. I don't want to trust TestCA. I don't know what other things it might issue in the future. In fact, there was a few well-publicized cases this year of CAs that had issued certificates to phishers. And they'd issued them to some name that was just a few characters off of, say, a banking site name.

And these all were perfectly legitimate certificates, and the system trusted them because they were issued by a trusted route. So I don't necessarily know what else TestCA is going to issue in the future. So I don't want to trust it right now. I just want to go to this particular web page and be done with it. So I can continue. And remember, authentication is required to change this, but this time around, I don't have to be an admin user to change this. I just get asked for my local account password, my password, to make changes here. So I'll enter it.

And I'm into the site, and I can see the little icon up here that shows me I've made a SSL connection, and that particular certificate is trusted. So the acid test, of course, is what happens if I quit Safari here and twiddle my thumbs and then come back later on and I fire it up again and I want to go to that same site? So let's go there. And it just goes there because the cert is already trusted.

Now, if I were to log in as a different user, that would be a different story because only this user has trusted that particular cert. And let's take a look at what that actually did under the hood. Here is keychain access. And I see in here that I have that certificate that I just trusted in my keychain. I can look at the details. But what I really want to show you is the trust settings.

This is the same API that's been in Tiger and you're probably familiar with. It's not the final API. We're still working on this. None of the UI changes have actually made it into the developer seat at this point. But the real thing to note here is the fact that I'm only trusting this for a particular policy, SSL, and just general X.509 operations, but I'm not trusting it for anything else. So the amount of granularity and control I have is a lot finer than saying, oh, I trust the very root and everything under it that it does.

So while we're in Keychain Access, let me look at some of my other keychains here. And over here on the left, I have a category called My Certificates. Now, that's just showing your digital identities, the things that are a certificate plus a private key. Other interfaces call it Your Certificates or Digital Identities, different terminology for the same thing. But I have one here issued to, this is actually my .Mac cert for iChat.

And I have a few others here. If I narrow it down, I can see that I've got one issued to this identity, which is security dev that I sometimes go by. And this identity, of course, which I use at work, it's a test CA. So keep that in mind as I go back here. I've set up this web server up here to also require SSL clans. And I can see that I've got a lot of authentication when I go to a particular page.

Now, when I do that, What happened here? Well, let's step back a minute. I clicked there. I requested that page from the web server. The web server said, ah, to get here, you need to authenticate. You need to send me a client identity. And what did Safari do? Well, it happily went ahead and did that search. So it called secidentitysearchcreate and did exactly what I just told you to do.

But it stopped, and it didn't look for any more other than the first one. So it's sending the wrong one. And we know this is a bug. We're working to fix it. But let's just say maybe it got it right. So I'm going to say, OK, go ahead and try to use that.

Well, it failed. And the reason it failed is because my web server won't accept the .mac cert. It's set up to accept an Apple cert. So I get a panel here that shows me the different identities that I have and lets me pick one. So I'm going to pick one that I know will actually let me in. And I'll say continue. And now we see that Safari is actually using that identity that I picked.

And I can click there. And it lets me into the secure area of the site. Well, what did that do back in Keychain Access? Let's take a look. Now, in addition to that certificate, I've got an identity preference item. And if you'll notice, the identity preference maps to a URI.

So that particular web page that I went to is mapped to my identity for that web page, Canva Cloud. And so I can use the APIs to look that up and pick the right one in the future. So with that, if we can go back to the slides here.

I want to talk about what you can actually do. That was obviously an example of using identities. But there's some new stuff in Leopard that's pretty exciting. And one of those things is the ability to sign and encrypt messages with identities. We have a new call that can do that in one function call, and that's called CMS Encode. CMS Encode, you'll find that in the security framework in CMS Encoder, is kind of a one-shot thing where you need to sign or encrypt something.

You've already looked up your identity. You know how to do that. So you can pass that in as the signer. And you know how to find other people's certificates. There's a preference thing. There's a lookup for that. If you have sex certificate references, you pass those in for the people that are the recipients of this message. And it just works.

Ken McLeod The thing I just showed you, obviously, was client-side authentication via TLS SSL. Under the covers, Safari, of course, is using Secure Transport. And Secure Transport has an API call, SSL Set Certificate, that actually takes the certificate that it looked up using those identity APIs and sets it on the SSL connection, and that's used as the client identity. Ken McLeod Now, obviously, this isn't everything. You can get lower-level access to the actual client.

Ken McLeod So, you can call your key and certificate, given an identity, by calling some of these accessors here that are in the Sec Identity header. Copy Certificate will give you a certificate, and Copy Private Key will give you a reference to the key that you can use in other cryptographic operations. Ken McLeod So, both of those headers will provide you the ability to go lower than that down to the CSSM layer. CSSM, of course, is part of CDSA, all these acronyms, the Common Security Services Manager. a set of APIs there.

We saw this dialogue before. This is the dialogue that Safari put up, and it's called SF Choose Identity Panel. This is kind of the standard way of choosing an identity on Mac OS X. It's perfectly available for your applications to use. It's in security interface, the framework there, and the header is sfchooseidentitypanel.h. This is either, in two flavors, a modal dialogue or a sheet, depending on your needs.

There's also a Carbon interface available to this. It's kind of hidden away. It's down in the security HI framework, and I don't believe it's included by default. You'd have to go in and manually add the header. The Carbon interface lags the Cocoa by a little bit. There's not as much granularity or flexibility in terms of what you can set, but it is there, and we're working on bringing that up to speed with the Cocoa version. If you don't have to put up a modal dialog, that is always better.

If you can use a pop-up menu and give the user a list that they don't have to wait and stop everything they're doing to pick it, but if they can kind of pick it out of band, for example, if you're composing a mail message, you may want to have a pop-up there.

Not that there is one in the developer seed, but that's just an example of, you know, a better way of picking an identity. If there is a preferred identity, and you know there is because you've called SecIdentityCopyPreference, then you can set that as the default choice if you're presenting a list of possible identities to the user.

And of course, another big scenario here is you need to ask trust questions from time to time. This is the same panel that Safari put up when it couldn't verify my certificate. What do I do now? And this is the standard what do I do now dialog in OS X. Obviously, Safari uses it. It's used elsewhere in the system. And it's available for your apps to use, too. It's in security interface. Again, it's either a modal dialog or a sheet. And there is a Carbon interface available in the same location.

So the final thing I'm going to talk about today is common crypto. And this was covered a little bit in Conrad's session earlier, but I just want to touch on it briefly in case you didn't get to that session. These are API functions for various commonly used cryptographic utilities.

What we discovered when we were putting this together, and we did a code review of OS X, I think in the Tiger time frame, is that a lot of different projects had the same code everywhere. They had copies of the SHA-1 and the MD5 hashing algorithms in their code. And this was littered everywhere.

And we wanted to collect that all into one place and have a nice, easy to use, available set of APIs in a standard location for your apps to use as well. And that standard location is user include common crypto. The implementation is in lib system, so your applications automatically get it when they're built, you just have to include the header files.

In Tiger and later, the digest algorithms are there. So for example, I mentioned MD5 and SHA-1, and there's the various other flavors of SHA, the secure hash algorithm. But in Leopard, what's been added to that is the ability to have symmetric encryption and also some HMAC algorithms there.

So obviously, one thing that people like to use is AES encryption, that's kind of the encryption standard. So that algorithm is available. And as we improve its performance, if you're using that common crypto version, you get the performance improvements as well on it. So for more information on these functions, there are man pages. And they are listed there.

Man-CC Crypto for the crypto functions, Man-CC SHA for the digest functions, and MD5 for the MD5 digests. What did we talk about? What should we take away here? First of all, just remember, a user can have more than one identity, and that's a key point. So your application should support that and ask the user to choose if there's some kind of ambiguity. You have a way to look for the preferred identity, the one that the user said to use. So there's APIs to do that.

You have Certificate Assistant if you want to be in the business of setting yourself up as a certificate authority and issue certificates. certificates to your users? Then of course, the thing I said was something not to forget. Don't rely on X.509 anchors anymore. It is not the source of trust after Tiger.

If you're needing to provide, you know, if you need to do anything with identities, the place to look is the security framework. That's got all of the API access functionality in its headers. The security interface framework is there for the UI portions. So all of that is there available for your application to use. In addition to those panels I showed you, also the certificate view itself is in there and public and available to display the contents of a single certificate.

So the last point, obviously, is that if you need encryption algorithms, there's no reason to roll your own. We have optimized versions. We have them there in Common Crypto. They're ready to use. So for more information on this stuff, The first place to go, obviously, is the developer website.

They have a security web page, and there's links on there to all the documentation we have and various other good sites and places to go. Get on the CDSA mailing list, the Common Data Security Architecture mailing list, if you are interested in this, because the data security team is hanging out there and ready to help answer your questions if we can.

The final place to look if you are an organization and you want Apple to ship your root certificate that you've created is the Apple Root Certificate Authority site, and that's off of www.apple.com. You see the link there if you need more information on that. And finally, for all things certificate, you can contact Craig, the go-to guy for security and various other things.