My name is Ken McLeod. I'm an engineer in the data security group at Apple. Data security is kind of responsible for all those security pieces, security framework, keychain, certificates, code signing and the like. So let's get started. Some of the things we'll be covering today, first just a bit of review. What exactly do we mean by a digital identity? We'll cover that.

And how do you get one? How do you create one? If you already got one, how do you import it? Just, you know, where does it come from? Once I've got it, how can I move it to another system? A big one here we're going to be covering is how certificates are actually trusted on Mac OS X. And this has changed. So, we're going to be talking about the different types of certificates in Mac OS X, X5 from previous systems, if you were familiar with those.

We'll talk a bit about how you find a user's preferred identity and what exactly a preferred identity is on OS X. Now, we're talking about OS X here, but all of this applies if you're an iPhone developer as well, because you'll be doing this on OS X when you're developing for iPhone.

And especially if you're going to use your identity for code signing, as we learned in the code signing session, you'll be able to find out how to do that here. So let's get started. First things first, what do we mean by identity? And identity is two things. The identity is a private key and a certificate. Now you need both of those and it's very important. The private key is something that you have and no one else has. That establishes who you are.

An identity answers the question, who am I? And I am the person that holds this key and nobody else has it. And the identity is also the certificate, which identifies you as the key holder and it also has some information about what you can do with that key, usually limiting the types of usages that you can do. It's very important.

We've had a lot of bug reports, people saying, well, I took my certificate and I copied it to another machine and it doesn't work. Well, you need both the certificate and the key to make up an identity and that's very important. I'll touch on that again later. Identities live in key chains and a key chain can be a standard file-based key chain on Mac OS X.

Key chains can also be tokens like smart cards that are secure that you plug in. We have something called a token D module that you can write and get more information about from the developer support site. Which supports different kinds of smart cards or tokens. And if you have an LDAP directory, you can look up certificates there. They can live in a user record if you have the appropriate attribute set that contain the certificates in the user record.

Here's something that's very important. A single user can have all sorts of identities. There's a one-to-many mapping here. I'm different people at work and at home. I have a different email address for each and I sort of have different uses for each of those. I can also have certificates from different issuers.

I can have one that's issued to me from .Mac or from Apple and I can have one that's issued to me from VeriSign or Thought. And I also have different identities based on what it is I'm doing. So if I'm signing email, that's one identity. If I'm encrypting data, that's another identity.

So here's the process. You start off by creating a key pair, a public-private key pair, locally on the user's machine. This is done for you by Safari in cases where you're going to a certificate authority's website. It ends up calling an API setkeycreatepair, which is in the security framework in setkey. And that creates a key pair for you on your computer. And then the next step is to take that public key and the browser will wrap it up in the form of a certificate signing request, a CSR. And that CSR gets sent off to the certificate authority.

The certificate authority processes it and signs your certificate. And when it's ready, you'll either download it or get it via email. And it'll go into your keychain where identities live. The kind of alternate method that we see a lot in enterprise and large organizations is where the certificate authority, sort of the IT infrastructure, generates the key pair and the cert and then pushes it to the user in some way. Typically, this is done by giving you a wrapped encrypted container, a P12 file. This PKCS 12 standard is an encrypted standard to let you transport it between machines.

You can also get it in the form of a smart card or a token that has your private key and your certificate on it. So that gets given to our user here, in this case, Bob, and then the end result is the same. He ends up with an identity, which is the private key and the certificate in his key chain on his computer. If you already have an identity from somewhere else, again, I mentioned the standard way of moving that around is with PKCS 12.

That's just a standard format. We support the extensions there, P12, PKCS 12, PFX. We see PFX when those files are created on Windows, typically. But it's a standard format, so you can bring those over, and you can either import them with the Keychain Access utility just by double-clicking or drag-and-drop or importing with the menu. You have most options that are available in Keychain Access are also available at the command line with the security tool.

It's in user bin. That really is a Swiss army knife of security-related functionality. And in this case, there's an import command that lets you import from a PKCS 12. You can also go down and use the API that that tool is calling, which is SecKeychainItemImport. That's been in there since Tiger in the SecImportExport header is where you'll find that.

In this case, if you were importing from a P12 file, you'll specify the constant KSEC format PKCS 12. Which says my input format is that. And if you have a key that you're bringing in from OpenSSL, there's a constant for that as well. So that lets you import all sorts of things.

The flip side of that, you can also export an identity that's in your keychain the same way. With the GUI with Keychain Access, you just select export and save it to the file. You can use the command line tool security export. There is also the API set keychain item export, which does exactly what you would think. And in this case, if I want to export to a P12 file, I can specify that constant and it will create the file for me.

Something that we've had as a feature request in previous WWDCs, people want to be able to import or create an identity in a keychain container and not have it be able to be exported. And that is possible. And the way to do that is to clear the extractable flag. There's a set of flags when you call set keychain item import that are passed in. And one of those flags is CSSM key adder extractable. And if that is cleared, then the private key cannot be removed from that keychain container or exported.

So when we're creating identities, here's kind of the blueprint, the template here. You'll want to either, well, we'll start by creating a certificate authority. And then you can use that certificate authority to issue certificates directly from there. Or what a lot of people will do is issue an intermediate certificate authority from that for a particular subset of the hierarchy of their business or organization. And the other thing to think about is you have to have some way of providing the root certificate to your users so they're able to set up a chain of trust. And we'll talk about how trust happens here.

So I've got these identities on my system. What are some of the opportunities? What are some of the things I can do? Well, first off, I could use an identity to sign or encrypt something. And the API for signing or encrypting that you'll be interested in here is CMS ENCODE.

CMS stands for Cryptographic Message Syntax. But that's, again, in the security framework. Look in the CMS ENCODER header and you'll find the API there. It takes a secidentity reference. So it's a reference to one of those identities. Remember the private key and the certificate. And then you can sign or encrypt something to some recipients whose certificates you've also looked up. Another thing you can do with identities, obviously, is client-side authentication. If you're using the secure transport APIs directly down at the lowest level of the stack here, you can use SSL set certificate to set a particular identity. That you'll use to authenticate.

Or if you're using CF Network, which is built on top of that, there is a property, KCF Stream SSL Certificates. And if you have an identity that you want to pass as the client certificate, you'll set that there. If you need even lower level access, SecIdentity has accessors to get out the certificate or the private key given an identity reference. And then you can do whatever functions in the SecCertificate or SecKey headers that you would need to do things individually with those.

How do I know out of all of the identities that I've got which one to use? Looking up is something that you're going to be doing. Well, there are a lot of considerations here. I could be needing an identity to sign an email with and perhaps I need to find one that matches my email address. That's kind of the common use case. I might be doing a SSL server and in that case I need to have an identity that matches perhaps the host name that I'm serving.

So, name is a consideration. Issuer is also a consideration. Obviously, if you're sending a client certificate, some servers will only accept identities that are signed by a particular CA. So, you may need to narrow it down that way. Usage is a consideration. Obviously, if you have something that requires encryption, you only want to get identities that will be able to be capable of doing encryption. You need an identity that can sign your code. Well, that narrows it down. Not every identity can sign code. So, you'll need to look for an identity that does that.

For most of that, you need to find out what the user wants. And there are preference considerations here because users, as I said, often have more than one identity. In the past, we've had even Apple applications fall into this trap where they just blindly picked an identity. Oh, that one matches. Let's use it. But no, you really have to have the user involved in this to say which identity is correct.

So all of these are considerations when looking up an identity. So how do we narrow that down? Well, one tool that came in with Leopard, Certificate Preferences, lets us specify which identity or certificate we want to use for a particular use. So if I have an email address, I can set up a preferred identity that's mapped to that email address.

Or if I'm visiting a particular server, I can set up an identity preference that maps the certificate I want to that server. I can also... The key usage. I can set up a signing key or encryption key for those purposes. These certificate preference items or identity preferences are just standard keychain items.

The advantage of that is you can sync them across machines. They're just normal keychain items. They go back and forth. Right now Safari and iChat are big users of these. We're seeing more uses come online. The standard use case here that we envision is that you'll only create these when you need to. So at the time that there's some ambiguity and you need to ask the user which identity do you want to use, at that time you can create a preference in line as needed.

But there will be cases where you can also create a preference manually ahead of time if you need to preconfigure a system to have a particular preference. And there's a few ways to do that. There is a lot of use cases that allow you to create a preference manually.

So let's go ahead and look at this. So this is the most common use case. If you're using a keychain access, you're going to have to create a preference in line, which is a keychain access. So you can set a preference in line, and you can also create a preference for a keychain access.

You can create a preference in line, which is a keychain access. You can create a preference in line, So the primary APIs that will be of interest here when working with certificate preferences, you have SecIdentityCopyPreference. Now, this lets you pass in the particular name or URL that you're looking for and to see if there is a preferred identity that the user is said to use. Now, this can return nil and be prepared for there to be no preference at that time.

And we'll talk about how to handle that in the next slide. There is also obviously a way to set that with set preference. SecCertificateCopyPreference lets you look up a preference for someone else. So for example, if I want to send an email to Perry or to Murph, they may have a preferred address that they want to receive or to use for encrypted email. And that preference will let me find out what that is.

And when you set that API-- excuse me. When you set that preference, the API to use is sex certificate set preference. So here's the general process for looking up an identity. On Mac OS X, you'll start with SecIdentityCopyPreference. That's just the first step. Is there a preferred identity? And if there is, you're done. You found it.

You can go ahead and use that identity. If there isn't, then you can look up what identities are available. And to do that, you'll use SecIdentitySearchCreate. SecIdentitySearchCreate lets you set up the parameters. And it's an iterative call. So you'll call SecIdentitySearchCopyNext to get as many as you need that match the criteria until you're done. Now, this is a pretty broad search, and there's not a lot of ways to narrow it other than by key usage.

You'll often have more than one identity that matches. And in that case, Throat's been doing this to me all week. In that case, you'll usually have to ask the user to choose. Now, iPhone is a little bit different. A lot of you have noticed that the security frameworks have diverged between the iPhone and Mac OS X. And unfortunately, they haven't converged yet.

We're on a path to bring them together. But the iPhone OS is first to implement sec item copy matching. Now, this is also coming to Mac OS X, the desktop as well. But this is kind of the next generation of looking up items, identities, keychain items, what have you, by passing in a CFDictionaryRef that comprises a dictionary of the things that you want to match. And it will return the items that it's found as a CFArray. And this is the direction we're going. So, we're going to be using the phone and the Mac OS X to try to merge APIs between the phone and Mac OS X.

So, I mentioned that there are going to be times when you have more than one match and you're going to have to ask the user to choose. There is a standard piece of user interface on Mac OS X here called SF Choose Identity Panel. And this has been available since 10.4. And it just lets you present a list of identities in a standard way the user can pick from.

If it all possible, don't make it modal. Modal is always a better solution. So if you can present that perhaps as a pop-up menu of choices that the user can pick from when they need to, that's kind of a better way than a modal dialog. If there is a preferred identity and you already know how to find it, you call secidentitycopypreference to find it. If there is one, that could be the default choice in your menu. So switching gears quickly.

There have been some changes since 10.4 and earlier in the trust model. It was pretty simple before. You had a single source of trust for all certificates. If the root certificate lived in X.509 anchors, then it was trusted. Now, The problem there is that you had to be an administrator in the system in order to get anything trusted or to add anything to that or modify it.

In Leopard 10.5 and later, there are actually things called trust domains. System trust is something that doesn't change. It's what ships out of the box. It is the set of root certificates Apple ships you. But you can override those in the admin trust domain by adding your own root certificates or own trust settings and even override things that Apple has said was trusted.

And then the user trust domain is a per user domain that can override both of those. Now, if you're an administrator that needs to disable that, there's a way to do that. But in general, the user has the ability to say which certificates they trust and to add trust just for their own user account.

So a key thing to remember here is that trust is no longer tied to where the certificate lives. There's no magic keychain location that if you put a certificate in, it's trusted. Certificates can essentially live anywhere. Don't put them in X.509 anchors anymore because that won't trust them.

So we provide again the system roots in system library keychains and there's actually several keychains there. But when you add a root certificate to the system, you can add it to the system keychain. Well, why there instead of anywhere else? The system keychain has the property of being shared across all user accounts.

So all user accounts can see the system keychain by default. So if you add a root certificate there, then it's able to be seen across the system. But it really doesn't matter. Your trusted root certificates can live actually in any keychain you want. The way we establish trust is by starting with a certificate we call the LEAF certificate, the one we're interested in. Is this trusted? And we look and see who signed it.

Typically that may be an intermediate or it may be the root. If there's another certificate that signed it, we look at it and so on until we get to one at the end of the chain that we can't go any further. It's signed itself. And if that certificate is trusted, then we've built a chain of trust and we know we can trust the LEAF certificate at the end.

Well, the problem here-- is that you're trusting an awful big scope of things by trusting the root certificate. If you're trusting something like VeriSign with the thousands and thousands of certificates they issue, you know, by trusting them, you're trusting everything they've issued. So there are cases where you'll want to narrow the scope of trust and maybe set a trusted anchor.

A little bit lower down the chain and this is trusting less things. And in fact, I can even say that just one certificate, just that leaf certificate is trusted and I don't have to go up any higher or extend any trust beyond that one certificate. So, there are, time for the water again.

So Leopard makes it pretty easy with Certificate Assistant to set up a CA and create certificates. And this has some things to think about, some implications. You obviously want to make sure that the private key that goes with that is trusted because your CA is only as trustworthy as, you know, that the private key is held in your possession.

If that gets out, then your CA is no longer trustworthy. If you're setting up systems for an organization or for, you know, a lab, there is a big kind of shift between 10.4 and 10.5. Previously, you added it to the X.500 Anchors keychain because that was the magic location that was trusted.

In Leopard, in X.509 and later, go ahead and add it to the system keychain if you want it to be seen across all users of the system. But you'll need to do an additional step. You'll need to mark the certificate as trusted. Now, how do I do that? Well, the security tool, obviously the jack-of-all-trades security tool, has an add-trusted cert command. And add-trusted cert lets me add trust in the admin domain.

We talked about the admin domain being an override of the system. And I can do that with the dash-D flag. Or I can add trust in the user domain. And that's just specific to one user. Again, I mentioned that if the administrator needs this ability, they can turn off user trust settings.

If you've got to validate your certificate chain all the way back to a root, rather than allowing those intermediate or leaf anchors, you can turn that off, again, with the security tool. Security, user trust settings enabled. And it has a disable or enable flag there. If you are using the API level, the Sec Trust APIs, you can use Sec Trust Set Anchor Certificates. And when you make that API call, that overrides anything, any user trust, admin trust that may be present there.

So here's the general way a certificate becomes trusted. When you encounter a certificate for the first time-- many of you have seen this in Safari when you go to a site that has a certificate you've never seen before-- you'll be asked on the first time it's used. This varies depending on your application. But the key thing here is that authentication is required in order to modify those settings. Root, of course, being root, can change trust without that authentication.

You can also use Keychain Access. It's got a GUI which actually you see the panel here as an example of how to change trust settings on a particular certificate. You can open that up and you have a variety of options to set trust on a per policy level.

Of course, all of that is available at the command line as well with the security add trust insert command. And then that's built on top of an API called set trust settings, set trust settings, which is quite a mouthful, but lets me set the trust settings. settings from an application.

So when you first encounter that untrusted certificate or you really need to ask the user what to do, and there's a standard way to ask a trust question. And you've probably seen a panel like this before in Safari. It's a standard piece of UI that your apps can use as well. SF Certificate Trust Panel. That's in the security interface framework. So if you need to ask a trust question when you're encountering untrusted certs, this is the thing that will let you do that.

It has all of the display built in so you don't have to write that code yourself. And it also has a nifty little thing here, a checkbox that lets me specify that I want to set the trust settings permanently. And in 10.5, we also narrow this down. So I don't think this is quite readable. But in this case, it lets me always trust a particular certificate only when going to a particular site. So trust settings have the ability to have constraints such as a particular site that you're using it for, a particular policy, and so on.

One word about an older API that you may have seen, SecTrustSetUserTrust. This differs from SecTrustSet-- I can't even say that-- SecTrustSettingsSetTrustSettings in that the first one wasn't really secured. It was just a preference. So when you called SecTrustSetUserTrust, it happily said, yes, the user said to trust that.

But there was no authentication. So any application could use that and just silently change the trust settings. Well, that wasn't a good thing. And we knew it wasn't a good thing. So SecTrustEvaluate, the main call to evaluate trust, never took that into account. This was just an advisory preference that your application could go after it had performed a trust evaluation and then called SecTrustGetUserTrust to see if that preference had been set. And you could do your own evaluation or take that into account. The difference with the new API, SecTrustSettingsSetTrust Settings, is that it actually is secured. And any time it's called, authentication is required to change it.

And because authentication is required, the main trust evaluator that's used, SecTrustEvaluate, which is at the heart of trust evaluations in Safari and iChat and wherever, will take that into account now. And in fact, the implementation of the former call is changed. So it's just a call through to the new call.

So I can set up trust settings on one machine, but wouldn't it be great if I could set up one machine and then replicate that to my entire lab or another machine that I have in my office? And you can do that with a pair of APIs here. You can create an external representation of your trust settings, which is just a CFDataRef, a blob, and then put that on another system.

Move that over and import it with the corresponding command, import external representation. And that lets me import into either the admin or the user domain and basically blast my configuration onto another machine. And of course, there are command line ways of doing this too. The security tool has trust settings export and trust settings import.

So with that, I'd like to switch over to the demo and kind of go through a demo of Certificate management. So the first thing I want to show you is how can I set up a certificate authority? In the last session, Perry said you could set up a certificate authority in five minutes. I think I can do it in less. So let's see.

In Keychain Access, there is a menu item, Certificate Assistant, and this lets me, among other things, create a certificate authority. This is an assistant, so it will walk me through the steps. The first thing I have to do, and this is kind of daunting, is pick a name for my CA. Ken's Certificate Authority doesn't sound official enough, so I'm going to go ahead and call it something like Ken's Platinum Assurance.

That gives me a warm feeling. I'm going to go ahead and take a look at some of the other panels. This is just a more than one panel option here. I'll set up an email address. This is obviously not my email address, but it's something to go on.

The thing I really want to show you is on the next panel here. The Certificate Assistant lets you specify a serial number for your cert. This is very important because certificates are unique by serial number. So it's important to change it to something other than one. I have a little trick. I just like to kind of put in today's date, which is I think the 12th. And this is the first cert I've made today. So we'll give it a number there. And we'll make it two years until it expires.

I can have a default template set up for the types of certs I'll issue, but I can override those, as I'll show you later. I'm not going to go ahead and do the signed invitation, so let's keep going here. I'll fill in my email address again and give myself an organization. Maybe I'm R&D and my organizational unit is software and I'm based in Cupertino. So put that in.

And that's pretty much the hardest part. I'll just accept the defaults for the key size here and the key extensions. They're typically set up the way I want them, so I'll just keep clicking through here. I'm going to go ahead and specify a location where this will go, my login keychain. So it creates the cert and I'm done.

Is anybody timing that? I'm now a certificate authority. So I look at my keychain and I see that, in fact, I have my identity. Now, remember, identity is not just the cert. Identity is also the private key. So I have both the certificate and the private key here.

And, in fact, there's a little category over here on the side, my certificates, that lets me see the ones that I'm going to use. So I can see the ones that are actually corresponding to a private key. And the little turn down there makes it simple to match those up.

So now that I'm a certificate authority, I want to assign myself a code signing certificate so I can start signing my code like the previous session told me I should. So back to Certificate Assistant and I'll create a new certificate. And, well, I won't just be Ken. Let's be Ken's software.

Oh, and I better be LLC to limit my liability. And this is going to be a lease certificate. Now, I'll override the defaults here just to show you what the options are. Again, the serial number has to be unique, so I'll give myself another one. And this is the second one, so it's 02.

Now this is important. What type of certificate is this going to be? Well, we have one of the defaults set up is code signing. So I'll go ahead and choose that. And by choosing that, that sets up all of my key usage and extended key usage extensions correctly in the next panels. So let's rip through those.

I am, again, some email address, some organization.

And I can choose an issuer to sign this certificate. Well, fortunately I just made one, so let's pick that. Again, all of these I can override if I want to, but they're set up correctly for me and I'll go ahead and create that.

Okay. So going back here, I see that I now have another identity. for my code signing identity for my company that I'm going to sign my code with. Well, okay, great. How do I do that? The new version of Xcode lets you do code signing with an identity. So let me open up my app here, my test app.

And in Xcode Now, I can look at the settings and I see that there is a set of options for code signing. One of these is I can pick a code signing identity to sign my code with. And I have an identity. It's Ken Software LLC. So that's great. That's all set up well. So let's build my app.

And it's compiling and linking. And now it asks me to code sign. Well, Xcode is just calling through to the command line version here, the code sign utility. And it knows that it wants to use my identity to sign my app. So since I'm going to do this more than once, probably, I'll always allow it. And then that just automates the process. I don't have to answer that anymore. Code sign has access. So let's take a look at my app, which I built.

And here, yes it is. Well, it doesn't look any different and if I run it, it just runs, but how do I know it's signed? Well, let's take a look with the code sign command. I can use the -d to display and because Perry has thoughtfully built in a lot of verbosity, I'll add some Vs to get more output. And I'll just take a look at this, oops, let's put a space there.

this app that I've signed. And I can see that in fact it did get signed. It was signed with my identifier, with my Ken software LLC authority that was signed in turn by a platinum assurance CA. So I won't go into all the things that you can do with code signing. That was the last session. But I just wanted to show you that much.

I do want to show you something that's very important. We've gotten a lot of bug reports about this, as I said. And I can't stress this enough. When you have an identity, it's not just the cert. It is two things. It is my certificate and my private key. So it's both of these things. And I want to make a backup of this. I want to move this identity to another machine so that I can do development on an iMac as well, let's say. So I can export both of these together.

One thing that makes it even easier, again, is this My Certificates. I can select it there and also export it. Remember we talked about the P12 format, PKCS 12. That's the encrypted container that will let me move from machine to machine. I see it's selected here by default. Call it my identity and I'll pick a location to save it to. And when I save it, it's an encrypted container, so it wants a password that will wrap this to keep it secure. So I'll give it one.

I'm going to export the key and now I have a P12 file that I can move around from machine to machine and import and I can back up and this is probably very important. I can back up somewhere safe so that I have a backup of that. So if something terrible went wrong like, oh my gosh, I just deleted. My identity, it's gone, oh no. Well, I have a backup, this P12 file that I can just double-click, import the identity. And remember that password that I put on the encrypted container. And it's back.

So the final thing I want to show you is not what I originally planned, but got quite a lot of questions and comments about something that's become a hot issue for a lot of people, client certificate authentication in Safari. This changed in 10.5.3, as many of you know. So let's take a look, first of all, at-- I picked them as a guinea pig-- MIT.

First of all, when we go to MIT, we see that there's an untrusted cert. What's going on here? We see that they have their own certificate authority, Massachusetts Institute of Technology, and I don't have their root. But Safari is using here the standard trust panel, SF Certificate Trust Panel, which we mentioned your app can use as well, to ask that trust question. Is this trusted? And I also have the option to always trust this when I'm going to that particular site. But let's just go ahead and continue.

The thing about this particular server is an HTTPS connection to MIT. They require a client certificate. And the change in Safari here can tell when a server has required a client certificate. And it uses that other piece of user interface that your app can also use, the SF Choose Identity panel, to present a list of possible certificates.

Because I have a bunch that I could use here, the one I just made or my iChat encryption certificate here. So it wants me to pick one. And I'll just go ahead and try to log in. Well, guess what? It wasn't accepted because I don't have any affiliation to MIT.

They haven't issued me anything, so I can't get in there. But what it did do is give me the opportunity to pick one. And that let me set an identity preference. So let's take a look at that. Over in Keychain Access, if I look here, I now have an item for that particular server. And this item specifies the preferred certificate that I just selected. Now I can change that if I want to later. But that's kind of automatic.

What we also have though is a case where a server is configured to optionally accept a certificate. This site I just showed you required one, so we were able to deal with that. Here's a server at Apache, and sending a client certificate to this server is completely optional.

And in this case, Safari doesn't prompt you. Well, we know it should, but what do we do about this? Well, we need to set an identity preference. So let's go back here. We'll grab the page that we're trying to go to. And we'll find the certificate that we want to use. So let's say it's this certificate here that I've issued.

I can directly create with this UI an identity preference here. For the particular page or, and this is not in 10.5.3 yet, but it is in an upcoming build, I can just specify one for the server itself and have it apply to any page that I go to on that server. So I'll go ahead and add that.

And next time I go back to this page and reload it, you see that the content here is a little bit different. I've actually, this time, sent a client certificate and I see which one it was. It was my Ken McLeod certificate signed by Apple Data Security Test CA. So that's sort of the workaround for now for those particular sites if they don't actually require the client certificate presentation as optional. So with that, I'd like to switch back to the slides.

And to sum up here, it's important to remember users are going to have multiple identities. They're going to have identities issued from perhaps your organization, perhaps from .Mac or MobileMe or whatever it's called. So there's going to be a plethora of them. So the first thing to do is always to look for the preferred identity and use SecIdentityCopyPreference to do that.

And then if you can't find a preferred identity, ask. You have tools to ask with. Very important to remember the trust model that no longer relies on location. So if you were formerly putting certificates into X.509 anchors to trust them, that no longer is the case on Leopard. And just be aware of that.

So we have a lot of tools for managing these certificates. At the high level, we have keychain access. That's sort of the top level user interface. And we have certificate assistant for letting you set up a certificate authority or issue your own certs. One thing I forgot to mention is that this won't actually let you put code on the iPhone with my Ken software LLC. If I wanted to actually put my code on the iPhone, I would need the certificate that was issued from WWDR to do that. At the command line level, you have security, the security tool in UserBin.

That's sort of your jack of all trades tool, your Swiss Army knife for dealing at the command line. The API level, security framework provides a lot of access with APIs. And the security interface framework there, which we saw two examples of, gives you some panels that are standard that do a lot of work for you in presenting certificates.

More information. So the security page on developer.apple.com has a bunch of links to obviously documentation and places to go to get more information here. A very good resource I want to point out is the CDSA mailing list. CDSA being the Common Data Security Architecture that is at the root of the security framework on Mac OS X.

But we have a lot of Apple people that monitor and read that list and there's a lot of questions that get asked and answered on that list. So it's a good resource for you. If your organization is interested in setting up a certificate authority that Apple provides and you want more information about that, there is a page to go to for the information and requirements for being a root CA in Mac OS X.

Craig, as always, is the person to contact for any kind of security-related technology request. If this is something that you don't want to share with us in the Q&A part, talk to Craig. If only there were a time machine. We have time machine but we don't have a time machine to go back and look at these. But these were the sessions that really relate to this. Obviously, if you have a chance later on and you didn't get a chance to go to these sessions, you'll want to check them out.