My name is Shawn Geddis. I'm security consulting engineer in Apple's enterprise division. And hopefully today most of you are either in the IT space or if you're a developer you just want to get a little bit more knowledge with respect to certificates. Because this is more, this session is geared more towards kind of the high level approach on certificates, validation uses of identities and things like that. So just to help set expectations.

Let's kind of move forward here. First of all, what do we mean by the use of identities and what is it that we really want to kind of introduce to you here today? When you're in kind of the digital world, you've got to prove who you are or kind of assert yourself.

So that's one of the things we want to get into is using trusted identities. We want to walk you through, hopefully we'll give you some new information here about the creation, the management and the use of those identities in the digital world. And that should then allow you to leverage the collaboration services we have built into the OS or things like on the phone. And then show you or kind of walk you through kind of that improved user experience related to the use of identities.

So again, kind of emphasizing here about the retrieving, storing and validating identities itself, the trust. There's a lot of folks within IT space that are moving towards heavy use of PKI certificates, the public private key approach here. And the whole concept trust gets a little bit complicated. We've been dealing with this kind of content for the last couple of years within WWDC. And we just have realized from experience with some attendees, we just need to kind of reinforce some of this as we go forward. But most of all, we want to show you some of those built-in services within OS X.

So as we talk about these identities or these services, these tools, we always have to step back and think about the problems we're trying to solve. The real world problems we're trying to solve in your organization, within your infrastructure. It's the assertion of who we are in this digital world.

How to acquire those identities and retain and protect them safely. The session just earlier was talking about secure application or secure programming. How do we do that with the identities? How do we keep that secure once we obtain it? How do we prove who we are and then are always able to assert that wherever we are? Again, collaboration with the trusted identities.

We want to generate and deploy this. Many of you may have begun to do some things with certificates. You may not know how best to do that deployment within your environment, how to get those certificates out to all your users, whether they be mobile or whether they be within a given building or organization. How do you get these identities to all your users?

So let's do this. First of all, I've been mentioning the word identity quite a bit here. What does it really mean? And from a standpoint of PKI here, an identity is really a certificate with a corresponding private key. Right? And the certificate, to most, it's easily understood if you think of kind of a bill of materials. You've got kind of a list of things and that pulls it all together. It's kind of the association of these objects.

And combining those two together effectively represents you as a unique identity, again, within this digital world. And that private key is something you have. So it's always this something you have and something you hold and protect. Again, that being the private key. And that comes into play all along the private and public key here.

So a typical identity, keep in mind whether you're in IT or whether you're on the development side, that many more instances, I as an individual or you, can have multiple identities. Right? I can have multiple identities for a given email address. I can sign my messages with an identity I get from, say, VeriSign or Thought or maybe I issue my own.

So don't always assume or take for granted that every individual is always going to have a single identity at all within this world. And a typical approach when we think of the storing of this identity is that I have a particular kind of identity with private key and the certificate.

And then we get into the email, we get into VPN, we get into client-side authentication for web access. These are going to be all the different usages. So let's start with the usage scenario that you're going to face is how do I obtain this as an end user, as an IT individual? How do I obtain an identity?

Well, there's a couple methods and the one that we most often use is obtaining that from some well-known certificate authority. We do the request, we get that issued to us, we have our identity. Well, you can go further. Here we're listing web-based and typically most of us are issuing maybe with VeriSign and others.

You think about .Mac, those of you who had .Mac services, you had iChat, you had similar things where you get your .Mac identity. iPhone, if you are an iPhone developer, you should have been issued your iPhone development identity as well. The final one is one that we're going to hit on a lot today and that is creating your own identity, creating your own certificate authority and taking kind of the issuance into your own hands.

So let's walk through this process. So if you're obtaining an identity from a CA, the first thing is I'm on Bob's computer here. So I'm going to create my public/private key pair and I'm then going to submit this as a request, a CSR, certificate signing request. I'm going to submit that to the CA, the certificate authority, saying please issue me a certificate for this purpose, for various purposes that, for maybe email, again for VPN, things like this. And once that is approved at the CA, that's going to be issued back to me for the actual certificate. Now again, remember that's that bill of materials now associates my keys, who I am and binds all that information together.

So if I do that effectively, that's one method. But another similar method is how about if the CA did the actual creation of those keys and pushed them all to me. So this would be, again, the situation of the certificate authority generating the key pairs on my behalf. This may be an environment like auto-enrollment where you are the IT admin and you are kind of pre-enrolling your users and pushing out their identity to them.

So the CA in this case generates the key pairs, signs the certificate itself and then does that wrapping of that identity into the P12 file. That's really kind of the secure wrapping of the full identity. Pushes it down to the individual, Bob's computer. They import that into their key chain in OS X. Now they have the same end result, their public/private key pair and their certificate. Again, two different methods of obtaining that CA.

Now, if you've got the actual P12 file that I was just mentioning, some of the scenarios of getting that into an OS X machine to manage that for use of various services is the simplest way is obviously the GUI. You just double click on the file. Keychain access comes up and asks you which keychain to import it into. Keychain being that secure credential store for that identity. Those can select the import menu option as well within keychain access.

But I'm probably pretty sure that most of you in the IT space are now wanting to think about how you script this on a large scale to a lot of your users, a lot of your machines. That's when you want to rely on the security command. And user bin security, that gives you the full capabilities of doing this management of the keychains, the importing and the trust you'll see in a little bit of these certificates and keys. So security command will be your best friend. If you're trying to script or do some kind of large scale deployment from the command line or from kind of back end tools.

The nice thing about this as well is keychain access and security tool also give you the ability of doing that export. So if you're either creating your own and you want to export that identity and share it between multiple machines that you may have personally or between multiple admin machines, again both the keychain access application itself and security gives you the export capabilities.

So, we take the next step. Great, I've got this identity myself, but how do I access these within OS X? How do I leverage that identity? The identities themselves are stored in a couple different places. First of all, we just walked through the typical store of your identities in a keychain. Most of you would probably store it in your login keychain.

Second of all, some of you might be familiar with or have heard about smart cards. Smart cards would be a physical kind of a token device that now is secure protection of that same kind of credential store. So if I had a smart card into my OS X system, I could be storing my identity on that smart card.

And then finally, when you are pulling either your own identity information or you're pulling public certs for the recipients, maybe you want to encrypt an email message to them, you'd be pulling it from a LDAP accessible directory service environment where you're, again, pulling those from the user certificate or the user SMIME certificate attributes within that directory service.

So that's where they're stored. And when you go to view this, if you're not familiar, within keychain access, as you open up keychain access window, down in the categories area, there are a couple category listed. There's been some confusion in the past. So certificates, they just would list the public certificates that you have in various keychains that you've got in your keychain list. When you select my certificates, that's showing you those identities. It's showing you the correlation or the association between the certificate and the corresponding private key. In this case, I'm just showing some of the identities that I had in my keychains here.

So many of you that are iPhone developers, this should look familiar to you. This would actually be the iPhone identity issued to you as a developer. And again, I just imported it into a different keychain. You see the keychain name there is iPhone Dev. You can have as many keychains as you need. You're not limited to one or two.

I think I have about five or six. And I typically do that for various purposes. I may store very public, kind of freely disposable items in one keychain that I just kind of discard or wipe out periodically. Those that are more secure, I may change the mechanism that protects it. Maybe I change the passphrase on that keychain or I protect it with a smart card. It gives me some different levels of protection.

So if you're doing a lookup, again, this is kind of where do we go to get these identities. When you're looking on both 10.4 and 10.5, there's kind of a two-prong approach or two-step configuration into pulling these identities from the directory services. The first is on that particular host needs to be configured for LDAP access to that remote directory store where the certificates are. 10.4, you use directory access. 10.5, you use directory utility.

The second step is within keychain access, this is the utility you're doing all the management of your identities, certs, you do the enablement in the preference panel there, do the enablement for search directory services for certificates. That then leverages all of those directory service entries you've created for those LDAP accessible directory services.

Now, when you have multiple identities, I may have, I think in my case for mail, I may have three or four. I have some identities for some other purposes. How do you go about selecting which one to use for each one of those services? And many of you have probably seen some various dialogues come up, windows that have a list of identities.

What's really happening is you have a, you're particularly accessing a service. It may be a secure website that you're accessing now and you need to select which identity you're going to use for that purpose. What would appear is a list of identities that match the usage of the service you're going to access.

And once you select that, you're going to have a list of identities. And once you select that, here's another option here for selecting yet another identity panel and you're seeing the full certificate view. What actually happens is it creates what we refer to as an identity preference. When it comes to PKI and the use of identities and certificates, Apple works very hard to reach kind of a zero configuration approach.

And so when you're needing to manage between which identity to leverage for these services, there comes a time where rather than throw that UI in front of the user, you need the OS to know which identity to use. This leverages those identity preferences. So if you weren't aware, within Keychain Access, you can manage and enter and create these identity preferences even manually.

I will show you a little bit of how the OS manages that. But you can manually select, do your contextual menus on that identity within Keychain Access, and you'll get a little pop up here. And you'll see that you can create identity preferences for URLs or email addresses. This gives you a manual way of picking and choosing which identity to leverage. And then you're going to select which certificate to use. In this case, it was kind of a reference to a SSL VPN server maybe that I was accessing at the time.

You're going to see the-- this is just a quick view of the identity preference itself. And at any time, if I want to go back and switch which identity that any application leveraging that network access for that particular type of service, it's always going to use the identity that I selected here. Quick view of what it looks like. It looks almost like the little V card within the keychain access here.

So we talk about obtaining, we talk about selecting these identities. When it comes to PKI, when it comes to certificates, you really-- everything comes down to validity. How do you validate this? And a little bit later, I have a colleague come up and talk about the trust model within OS X. But let's look at validating certificates. What does OS X do in trying to validate those certificates?

Within certificate validation, historically, there's been a method referred to as Certificate Revocation List, or CRL. It's kind of the legendary approach of solving this problem. And the way I describe it to many is, it's very much like downloading the whole phone book and then trying to look somebody up and trying to figure out whether they're still there or not, whether they're at the same address, they have the same phone number. It requires a lot of bandwidth. Right? You're downloading those huge phone books, and you can refresh that and get kind of a new copy of the book every year they publish it. But there's a lot of bandwidth. There's a lot of kind of data being pushed around.

New methods, new approaches to this, kind of a successor to CRL, is the OCSP, is the Online Certificate Status Protocol, which is very close to now you being able to call up that operator and saying, does this individual still exist, and where can I find them? Are they still valid?

Are they still employee of this organization? The process within OS X that does both CRL and OCSP is, in fact, the OCSPD process running. So many folks were looking for a CRL process, and they may be running TOP, and they're looking for it, and they didn't find it. It's all being managed by OCSPD to do the certificate validation for both CRL distribution points and for OCSP for the AI extensions.

Now, if you look in Keychain Access within the preference and you go over to the tab on certificates, we have the ability to set how you want those certificate validations to take place. In this case, by default, I was showing here about best attempt. That means it's going to go out and attempt to get the revocation list, the CRL, or in this case, get a response from OCSP.

And you can also set that up for prioritization. There are many folks that have either one or the other, CRL distribution pointer or OCSP. points in their certificates. We can set up the prioritization as you see here and either disable or set that up for best attempt for both types.

By default, they're both set to off, so it's not going to go out and do some additional validation on it. Any environments that you have that you want to do full end-to-end OS X validation, both Tumbleweed and CoreStreet have provided for quite some time the server validators for OS ASP on Mac OS X server. These are just some good references for you. So let me move on and hand things over to colleague Ken McLeod to walk you through the whole trust model within Mac OS X. All right. Thanks, Shawn.

Hi, everybody. I'm Ken McLeod. I'm an engineer in the data security group at Apple. Data security is responsible for, obviously, certificates, key chain, security frameworks, that sort of thing. What I'd like to talk about today is the second part. Shawn talked to you about an identity and what that means. That says who you are. That answers the question, who is this? This is somebody that's certified with a particular private key. But how do you know you can trust that person? How do you know you can trust the particular certificate that's being presented to you?

Well, we do this with X.509 validation and X.509 certificate trust validation starts off with a leaf certificate. This is the certificate that we're interested in to know whether it's trusted. So we look and see who signed that certificate and if the certificate is signed maybe by an intermediate, we can follow the chain back and see who signed that.

And at some point, we will get back to a certificate at the end of the chain that is signed itself at the end of the chain. And we ask the question, is that certificate signed? And if it is, then we've built a chain of trust from the leaf to the root and we know we can trust that leaf certificate that's been presented.

There's a problem with that. The farther back and the longer the chain is, the more certificates end up being signed by that route. If you chain back to VeriSign or one of the large CAs, they've issued thousands upon thousands of certificates. If you trust their route, you're essentially trusting everything that they may have signed and everything down the stream from them.

To solve that kind of problem and to be able to narrow the scope of what you trust, in Mac OS X 10.5, we allow you to specify a trusted anchor that is not a root but is rather further down the line. And in fact, I can take this to its logical conclusion and set my trust on an individual certificate. So I don't even have to build a chain beyond the particular certificate that I want to trust at the end there.

Now, 10.5 is very different in this respect from what came before. Before Leopard, we had a very simple trust model and there was a single source of trust. You had a root certificate and if it was in a special keychain container, X.509 anchors, many of you have heard of that X.509 anchors keychain, your root certificate had to go in there to establish any kind of trust. And of course, you had to be an administrator of the machine to do that.

But this got a lot easier with Leopard. In Leopard, we no longer use a particular location as the source of trust. So X.509 Anchors is no longer magic and putting something in there will not cause it to be trusted. Instead, there are three levels, there are three domains. And we have the same root certificates that we provided in X.509 Anchors are still there. They're in a new keychain called system root certificates.

But again, where they live is not as important as the fact that they're trusted. So the system provided ones go in that keychain. And then there's another level where you can override that or add to it. You can add your own root certificates to start a chain in the system keychain. Now, why the system keychain if it doesn't matter where they live?

The system keychain is the keychain that every user can see. It's configured to be available to every user of the system. So it's a handy place to store root certificates if you want multiple users to see them. But of course, they don't have to go there. If you have certificates that only you trust in one particular user account, they can go anywhere.

So there are three what we call trust domains here. And we have the system trust domain, which is kind of at the lowest level. This is what ships out of the box in Mac OS X. This is what Apple provides to you. And Apple has said, these things are trusted out of the box.

We give you Ferris sign and whoever else, the standard list of root CAs that are trusted. You can override this in the next level, which is the admin trust domain, by either saying these things are not trusted that Apple provided, or maybe you've added some of your own and you say, these are in addition and I want to trust them as well.

Now, the admin trust domain is seen by all users of the system. It applies across the board to every user account. In your own user account, you have a user trust domain. And you can specify that certain things can override either what's specified by the administrator. Or what's specified by Apple in the system domain.

Now, I should point out that some of you were concerned by that in sessions past. That is able to be disabled. So if an administrator does not want a user trust domain on the system to override their choices when they've set up, it can be disabled. I'll show you that in a little bit.

In 10.5, it's pretty easy to create an identity and to create a certificate authority. And a certificate authority is really nothing more than just a identity that's allowed to sign other certs. But it's kind of special in that you really want it to be trustworthy if you are a certificate authority.

And the only way to do that is to know that you are the only person that has the private key, that has access and is able to use that certificate authority. So you really have to think about securing that. And in fact, the large CAs have a very complicated process for securing those that involves locked rooms and steel cages and armed guards and that sort of thing, just like the movies.

And these are things that you actually have to think about because if somebody gets hold of your private key, they essentially have stolen that identity and they can issue things and, you know, a certificate issued from that certificate authority would be indistinguishable from one that you had issued. So another way of keeping things secure is to make sure that when you issue certificates that the key usage is limited, that you only issue things or you only use the certificate for a particular use that you need it for and not across the board.

So these changes that were introduced in 10.5 have some pretty big implications for people, especially supporting large organizations, universities, you know, IT. You've got a new trust model to deal with. Now, previously, all you had to do was add a certificate to the X.509 Anchors keychain and you were done. It was trusted. You were set up.

On Leopard and later, you'll need to put your, obviously, certificate somewhere. We recommend the system keychain because it's one that's available for everyone. But you'll also have to add trust to that as a separate step. And Shawn mentioned the security command, which is in user bin security. That's a very handy tool for doing all sorts of configuration related to security and trust.

Specifically here, there's an add trusted cert command that will let you add a certificate with particular trust settings that you specify. And I'll give you a little demo of that in a minute here. If you add it to the admin domain by passing the dash D option, you won't have any interaction required and you can write a script that does automatic setup for your organization.

So how exactly does a certificate go from just being a certificate to actually gaining trust? Again, out of the box, if it chains back to one of those trusted things, we know we can trust it. But very often you will encounter a website or you'll communicate with some other entity and their certificate you'll not have seen before and it won't be trusted. So how do you bootstrap that?

Usually it's best to do this on the first time you've seen it. You encounter it right at the time that the certificate is being used. And the sort of canonical example here is Safari. If you go to an HTTPS website in Safari and it is signed with an untrusted certificate, you get a little dialogue that asks, do you trust this at that time? And you can trust the certificate because there's separate trust domains. You can either trust it on a per user basis for the user trust domain or for all users with the admin trust domain.

The keychain access utility lets you go in manually and edit any trust settings on certificates. The diagram there that you see is what that looks like when you open up a certificate. For various usages, you have the ability to say, I trust this, but perhaps I don't trust it for another usage. And again, anything or almost anything you can do in keychain access can be done on the command line with the security tool.

So the security tool lets you add trusted cert to add and change the trust settings. And it also has a handy thing called trust settings import, which lets you take a canned file of trust settings and sort of duplicate those, replicate them across many machines if you need to set them up.

So here's that dialogue I alluded to that you see in Safari and other places. It's a SF certificate trust panel. That is something that's provided in the security interface framework. And it's a standard certificate dialogue for OS X. So you'll see this in Safari. You'll see it in Mail, iCal, things that need to ask a trust question. I've encountered a certificate. I'm not able to build that chain of trust. So what do I do? And-- excuse me.

In Safari here and in other places, you'll notice that you have the ability in 10.5 to add a little bit of restriction to how you trust the certificate. For example, I may not want to trust the certificate across the board for every use. I only want to trust it when I'm going to one particular website and the UI gives you the ability to narrow down that trust here. So let me switch over to the demo machine here and give you a look at what that process looks like for starting trust.

Again, Safari is kind of a canonical example here. I'll go to a site and the first time I've gone to this Red Hat site, I noticed that it, well, doesn't have a trusted certificate. And I can examine that, look at the details here, and I see that Red Hat has a certificate that was issued by something called Certificate Shack. Well, I... I have never heard of certificate shack and I don't know how big the shack is and whether they're dealing stuff out of the back. I really don't know too much about them.

So I would be very leery of taking the certificate shack route and trusting it across the board of my system. But because we have the user trust domain and the ability to extend trust only to one particular cert, I can decide to trust just the Red Hat server and additionally specify that I only want to trust this when I'm actually going to that site.

So because this is a change in trust, I need to authenticate. I'll type in my password here. And when I go and examine the certificate chain up here by clicking the lock icon that's up in the corner, I can see that the Red Hat server now is marked as trusted.

We have a new status that I've trusted this for this account and the user trust domain. And the thing to notice here is that there's only one certificate now because the chain only needed to be built just at that one certificate. And I didn't need to build it all the way back to certificate shack in order to trust the certificate.

Let's look at another example. A server at the University of Maryland. They're an interesting case because they have set up a complete certificate authority for their organization and they have a route that they created and then they issued a certificate from it, an intermediate and then another server signing cert and they have it parceled out in a nice hierarchy here.

Now, of course, if I just want to go to this one particular web server at the University of Maryland, I could trust it just like I trusted the Red Hat site. But let me put on my system administrator hat for a minute and think about this. You know, I really want to extend trust to the whole organization and I want to set up my machine or multiple machines so that I'm not bothered with these dialogues and I just trust it across the board. So let's look at another way to extend trust.

I've downloaded the route for this particular organization here and I'll just open it up. When I open it, it opens up in keychain access and asks me, do I want to add the certificate? Now, remember, if I want to add it in a way that all accounts across the system can see it, I should add it to the system keychain. So I'll go ahead and do that. And in order to add it, I need to authenticate.

All I did there was just add it to the system keychain. And remember, it's very important, just being in a particular keychain does not trust the certificate. Trust is completely separate from where the cert lives. So I'm additionally asked if I want to trust this particular route. I'll go ahead and do that. And again, it's a decision that requires authentication.

Now I can go into the system keychain and I see that I have this certificate and it's marked as trusted for all users because it's trusted in the admin domain. So if I was to go back to this server here,

So let's look at a few more options we have, in this case on the command line.

I don't necessarily need to, as I showed you with the checkbox, to trust a certificate at just the granularity across the board. I can trust it for a particular server and I can add conditions to trust that. The security command here, again, it's very versatile. It's add trusted cert.

It has a variety of options. And the first option there, minus D, is the one that you use to control whether it's in the admin domain, this is a decision across all users, or the user domain. And there's a variety of other ones here, policy, I won't get into all of them, app, policy strings, allowed errors, but what I'll go ahead and do here is show you a sample command that adds a trusted certificate.

I've passed in here the minus D option, which says that I want this to be in the admin domain. I've passed a minus K option, which is a particular keychain that I want to add this to, in this case, the system keychain. And then the file that contains my certificate that I want to trust.

So I'll go ahead and execute this command. And it just executes because, as many of you have noticed already, I'm running a root shell here, so it just works. So if we look at what the trust settings are now in keychain access, I'll look in the system keychain, and I now have an Apple data security root that I've marked as trusted. And that's just one way to set things up here. But I can also take a snapshot here. with trust settings export. Now trust settings export will let me, Either export all the system trust settings or just a particular user's trust settings. So let me quickly.

I'm going to dump what I've got here, -d again, the admin domain, and I'll save that to a temporary file. It tells me that I've done it successfully. And then I can go back in, and if I'm a student, maybe I'm mucking around or I'm changing this configuration, I'll go ahead and remove the trust here. I'll never trust this one.

And I'll authenticate to make that change. And that's no longer trusted and I can make some other changes. But what I can do at the end of the day, is reverse those and take the snapshot that I made earlier and use trust settings import to blast it back into place. So I'll do the reverse of what I did here using that file and import the trust settings. And now if we look back here, we'll see things are exactly back to the way they were when I took the snapshot and my data security server is trusted again.

So that's kind of a high level basic overview of setting up trust on Mac OS X. I have a session on Thursday at I believe 5:00, session 427, that gets more in depth into this. So I hope that if you're interested you'll come to that. And with that I'd like to turn it back over to Shawn. So if we could have the slide machine back. Thanks. Thank you, Ken.

So what we want to spend a little bit of time now on is many of you kind of wanted to, again, take the issuance into your own hand and you wanted to be able to start creating your own CAs and issue your own certificates, maybe for creating your own services within a work group or within an agency to just maybe even set up a test lab and test some of these services. So what we want to do is share a little bit of what you can do with creating these identities using the built-in services within OS X.

Now, when you create these identities, first of all, you need to define your root certificate. What Ken was just showing you is that whole trust model going back to the trusted root, the anchor. And what you first of all do is define your own root certificate authority, that kind of central third party authority that does the whole validation of certificates.

And then you're going to issue either an intermediate, kind of a sub CA. I think Ken was showing you a couple of them where they had a couple intermediates in line there. And then ultimately you're going to issue those certificates to your end users for various purposes, maybe for SMIME.

So if you think about your thought process through this and how you want to issue this in your environment, of course we're going to start with the root CA. So it's kind of my enterprise. I'm going to create my own certificate authority. Well, as I go forward, the first thing I need to think about is how am I going to separate kind of the usage.

Ken had mentioned it's very good to create certificates, particularly in this case, that have a particular or a single usage. So I'm going to create an intermediate, and the only purpose for that intermediate is to sign SMIME certificates for your end users. So you have a limited scope of what that intermediate can do.

At this point, then I'm issuing certificates for my users, right? Joe user at my company or my organization. And I can then be issuing to each one of my users just for the sole purposes for S/MIME. I would take that further. Maybe there's some in-house coding going on. So now I'm going to create a code signing intermediate that, again, does the same kind of thing as issue those certificates for the developers.

Some folks might think that this would be easier. Why don't you just create those intermediates to do everything? You know, kind of the key usage of any. Separating the usage, again, limits scope. It limits the kind of your exposure if for any reason the initial identity, the private key for that particular usage was compromised in any way. You can go ahead and revoke that and issue a new certificate for that purpose without revoking it.

You can go ahead and revoke that and issue a new certificate for that purpose without revoking the whole function for all your services for all your users. So, again, it limits scope, gives you a little bit of better control with the issuance of certificates. So as you look at your cert, right, so here's my root certificate authority that I created. And the key thing is that the only function that this root has is for digital signature and the key cert signing. That's the only functionality that that root has.

So a thing to keep in mind, now we're kind of drawing a little bit of the differences between the phone and OS X, because everything that we've been talking about really applies to both of those environments. First of all, the key point about the phone is that it's the same root certificates in the phone with the 2.0 release as is available and shipped in 10.5.3. So those root certificates, as Ken had mentioned, in the system root keychain, those are the exact same ones that are in the phone.

And the way to get or add additional anchors to the phone itself, there's three methods. And typically those are going to be done within IT departments with configuration profiles. But you can also get those onto the phones through email attachments, where again they would be opened up from the phone side. Or they would be accessing a secure website and again opening up that particular object itself, downloading it in Safari and adding it to the, you know, the OS X. particular phone itself.

So we've been creating, we've been issuing, we've been kind of viewing all this stuff. Where can you use it as a user? We've been referring to Safari as kind of the typical app. Of course, in mail, you can do the sign-in encryption of email with these identities. iChat, hopefully many of you have been leveraging the secure iChat capabilities where you can encrypt your text messaging, your video and audio with other .Mac customers.

Back to my Mac. You aren't aware of or you're not really doing any kind of configuration yourself related to certificates for the Back to my Mac. But when you enable that between two machines, it's leveraging your identity associated with that .Mac account. That ties in with the local KDC that is being used for Back to my Mac.

The VPN. Just about all of you are probably using either Layer 2 or Point to Point or now you may be doing or leveraging more of the PureVPN. The Pure IPsec that's available with the phone. Again, a key area that you'll be using these identities that either you issue yourself with certificate assistant or you're getting from another certificate authority. 802.1X. And if you're into the development realm, again, code signing. The other points I wanted to bring out about this is historically the iChat certificates or the certificates to use for encryption of iChat sessions was always automatically being done.

And leveraged when you're using iChat AV itself. But with certificate assistant, you can actually issue certificates with the capability of doing the encryption for iChat sessions. That would give you the ability to issue your own search within your own kind of organization environment. Again, the same with code signing. Issue your own code signing certificates from the certificate assistant if you're not part of the iPhone development.

This is a couple kind of walkthrough of the applications. Ken was talking about the typical dialogues you face. Earlier I had mentioned about the leveraging of identities and setting the identity preferences. If you're hitting websites, if things are requiring client-side authentication, you're going to be prompted with a selection of one of those identities. If you're in mail, and I always bring this up as a good example, just to be sure that folks truly understand how mail automatically picks up the use of your identity. In this case, the account that I'm leveraging is my Geddis at Apple.com account.

And you'll note that it's all lowercase. And what mail was doing is requesting to the OS, is there a corresponding identity, essentially with a certificate with the ability of doing digital signature, with an email address, or the RFC822 name, with Geddis at Apple.com. So it's kind of the default. It's happening on my behalf without me specifically configuring mail to do this. Now, if I had configured mail to have an uppercase G, lowercase e-d-d-i-s, mail would not be showing me the ability of digitally signing that message by default.

And one of the points that we always bring out to IT folks is that we're very much conforming to the RFC that everything to the left of the at symbol is case sensitive. And it's an environment that is frequently ignored in other mail agents. So take note on OS X that in this case, I need to be sure that the case of everything to the left of the at symbol matches what's in my certificate. It's a very key piece.

Same thing when I'm going to send the email message to an individual, in this case, Joe User. If I key in their email address and I have access either inside one of my keychains to their public certificate or a LDAP store that I can pull it from, I would then be able to encrypt that message to them. But in a like manner, as I just mentioned in my digitally signing and matching the case sensitivity, same thing with the encryption to a recipient itself.

You'll note in iChat AV, I'm not going to be able to encrypt that message to them. But in iChat AV now, it's kind of an update recently, is that you have the ability of selecting between which certificates you're using for the signing and encryption within iChat. Previously, you kind of had an on and off.

You enabled iChat encryption, and that was kind of it. It was kind of an on or off situation. Here, you're also able to select which ones are in use. This gives you the ability, again, going back, and if you wanted to issue your own certificates out of the certificate assistant, we're issuing this from your own enterprise CA, you could now select those certificates.

Some of the good related sessions to some of the content that we've hit here. Again, this was very much of a high-level discussion. We could spend a while getting and burrowing down into each type of service or use of trust and certificates. One of the key ones is managing secure data on the iPhone. That's later in the week on Thursday. Signing your application identity with code signing.

That's now taking your iPhone identity that you get issued by Developer Relations, leveraging that with your applications, pushing it onto the phone. And then, of course, a more technical, lower-level API discussion, very much of similar content that we covered here today. Ken will be doing managing X.509 certificates and digital identities. also in the afternoon on Thursday. So I think at this point probably the best thing is to shift on over to Q&A. I'll turn things over to Jason.