Welcome to Understanding PKI and Certificate Management. We've done some coverage of this last year, but it still seems that there's some IT organizations that have a little bit of struggle understanding kind of the whole trust model and the whole certificate management within the OS. So we really kind of wanted to readdress this and we're going to be hitting on obviously some Leopard features as well. So let's jump right on in. Welcome, my name is Shawn Geddis. I'm a Security Consulting Engineer in the Enterprise division in Apple Sales. So let's cover this a little bit more in depth.

First of all, what do we want to introduce to you all? There's the reliance on trust. So we're going to talk about trusted identities in the digital world. We're going to talk about creating, managing and distributing digital identities. We're going to be covering enabling security enhanced collaboration once you have these identities, what can you do with them? What kind of services? And hopefully highlight the approach that Apple has taken to simplify the whole kind of PKI as it's deployed in systems.

So hopefully out of that you're going to learn what exactly an identity is. If you are new to this space, if you're kind of getting your feet wet, learning how, what solutions you have to use or what kind of tools you need use, you're going to learn a little bit more about identities themselves.

How you need to go about retrieving, storing and validating those identities. Establishing the trust, because again this is the key with PKI dealing with certificates is establishing and validating that trust. Services like signing and encrypting and authenticating. And of course we want to highlight the built in services that we have in the OS that you can directly rely on as an end user, as an administrator, really in the deployment and use of, of these identities.

So in a lot of these discussions we at least have to get it all on the same page and figure out what it is that we're trying to, to solve. What problems are you trying to address with deploying identities? And first of all, in the digital world you have to prove who you are.

So some assertion that I'm Shawn and I have to prove that in some manner. So that's a user experience challenge we have. Second is if I'm going to prove that, how in the world do I acquire this object, whatever it is that I'm, I'm proving who I am.

Then once I get that, how do I retain it? How do I protect it? How do I take it with me? The portability. Because I'm, I'm a moving individual, I move between systems, I physically move it...move between states or countries, how do I keep that with me? Protecting the confidentiality and of course the data integrity. How do I use these identities, the certificates and keys involved to protect my information? Make sure that only the right people see this? And of course some of the other collaboration with trusted identity.

On the IT side, so if your administration, if you're the managing infrastructure on this, what are some of the challenges that you're trying to solve? First of all, how do you verify, if I'm an individual and I'm asserting that I'm Shawn Geddis, how do you on the back end, how do you validate that? Right, how do you prove that indeed I am who say I am? And how do generate this? How do you do all the management of those identities, whether they are users or machine? And then again how do you leverage the built in services? There's always going to be some third party solutions as well, but we want to specifically talk about the built in services.

Okay, so for some of you that are new to this and just kind of review for others, let's talk about some of the key pieces of PKI. There's a lot of folks, a lot of end users and I'm probably sure that each one of you have these. End users that say could you install PKI on my system. As if it's an application or a particular tool. There's a lot more to it. There's a lot more pieces, most of the, the services that many folks will talk about are the certificate authorities, which we're going to talk about today.

The registration authorities, that's basically how you're getting things started with the issuance piece. The certificate server. That's really kind of tied in more with your directories. And then time stamps, really when you're validating that. But the key take away today is we're going to be focusing a lot on the CA, and then reliance on a trusted third party. That's really the basis of PKI.

So let's look at some of the components. Again this is kind of review hopefully for most of you. New information for some. The whole thing in PKI is, is the cryptography of the whole asymmetric public, private keys. Right and the combination of these keys, it's a mathematical relation, so if I encrypt something with a public key, I can decrypt it with a private key solution. Again this is all tied into the certificates as well.

And the public key of course is available in the certificates. Its issued...with again you're doing a request and we're going to cover each one of these. You're doing your generation of your keys in the reference to the public key as part of your certificate. You verify the signatures with the private again that's that asymmetric association. And then you're going to encrypt that data to be sent to some user. For instance, you use a public key from someone to encrypt that message.

The private key is what I as a user would retain to, to do my decryption of data coming to me to again associated with my assertion of who I am, signing data and all. Again that's the association of the keys. I've mentioned a couple of times, the reference to my identity. So what is an identity? It's that combination of the pairing of that certificate and the corresponding private key. So they go hand in hand together being that identity.

And the certificate itself, you see a whole bunch of the information related to the certificate. Think of for some that new to PKI, a certificate is very much of like a, a bill of materials. When you're shipping a lot of product, it's the, the reference to all the components that make up that whole package. And then of course the associated with the private key is something you have and you retain. So let me move on here.

When you think of an identity, we typically think of okay, I'm only myself. But in the digital world you may be asserting that a different identity or multiple identities. That could be something with, again here, references different names or email addresses. It could be issued by different issuers, different certificate authorities, and it could actually have different usages for each one of those identities as well.

So you have the ability and the frequent use of having multiple identities. So let's run through each one of these areas and hopefully give you some insight about how we're doing this on OS X and how you need to kind of tie into to some of these services.

Obtaining an identity. I mentioned about first off you have to get that identity to be able to assert who you are in the digital world. And these are all issued and available from a certificate authority or a CA. And the two typical methods of that is you're going to request it from some well known certificate authority, or you're going to create your own. You either rely on the expertise of someone else or you take that issuance into your own hands. And again we're going to cover some of these today both in kind of the presentation and also some of the demonstrations here.

So let's walk through how you would do this with a trusted third party, a traditional certificate authority in a acquiring this identity. So on Bob's computer I'm going to generate my key pairs locally. And I'm then doing this request to the certificate authority to sign my request. To actually issue me a certificate. So the request is a CSR, certificate signing request. And that new certificate really comes back down from the certificate authority once they've validated all my information and they say good to go. I get that issued back to me, downloaded into the keychain. Really in kind of side.

Well, you take a slightly alternate method. And this is where the generation of the key pairs aren't down on the client side, they're actually generated on the back end, on the CA or on the infrastructure that the organization is using for the issuance. So in this case, the certificate authority has generated my public private keys and has already essentially signed my certificate.

And is now issuing me that as an object. Okay, the object could be a P12 file. It's kind of a wrapping of the private key in that certificate or it could actually be in something like a smart card. Protection there of my identity. So I already have it in a physical keychain.

That's how I finally get that back and available to my system. If I get, if I get in a P12 file format, I will, I would import it right into my keychain. If I had it in a smart card, I now have it available with me portable between systems.

Okay, if you already have the infrastructure and you already have your CA in place and you've issued these, how do you bring that into OS X environment? Well again the standard format is what I just mentioned, the P12 where it really is a wrapping of the private key and the certificate. And typically it's a file based, its password protected, and you're exporting it from your issuance, typically some folks will do like IE on, on a Windows side receives their identity, save it as a P12 file and take it on over to particularly their Mac environment.

Well, once you have that P12 file, in keychain access, you can just import that, directly from import menu, you can drag it on top of keychain access. We're going to do a little bit showing of that later on. But many of you actually need to script this in kind of in deployment environments.

You can leverage the security command in user bin security. And physically import that key. Import that, the rapid, wrapped P12 content into the keychain whether you want to do it into the log in keychain or specific users keychain. Now we also are going to cover today the creation of certificates, creation of identities.

Again, remember we talked about two methods. One is your request and have someone else do it for you. The second is you take that into your own hands and you do the issuance. That's where you would define your own root certificate. You do the issuance from your own CA or sub CA and you, then you provide those root certificates to all your users. That's where if you created a community of interest, you know various collaborative environments that you wanted to issue your own certificates for that outside of the, a commercial CA, you just wanted to issue it inside your organization, again this is a good typical use of that.

We talked about obtaining, now how do I access these? Whether you're going to send encrypted email messages or you're going to access even your own identities locally on the machine, how do we get to this? Well, your identities are actually stored physically in keychain files. And you would see this within keychain access or like I mentioned with a smart card. And right now those are typically the storage locally for users.

But many of you need to get to, for instance, the public certificate for folks if you're going to send them encrypted content through mail or other means. You need to get access to that public certificate. Well the method is to have a publicly accessible or within your network, an LDAP accessible directory service that within OS X can pull that certificate directly from that LDAP accessible server. We're going to talk about a little bit about that further. But the two attributes we're pulling are the user certificate and the user S/MIME certificate.

Okay. So if I'm viewing this, this view here of keychain access is actually a new view of Leopard and you'll see there that I've selected my certificates on the left. Right, some people have gotten confused by that. The certificates entry is just certificates. When I select my certificates, that those are really identities. Those are showing the certificates and the corresponding private keys, and again this was used for Leopard for 10.5. And you'll see that we're actually now showing you the pairing of which private key to which certificate. And that's new. That wasn't available in 10.4.

( Clapping. ) I didn't do it, but. So locating I mentioned about the LDAP accessible. Some folks have been unsure about how to do this. So there two components to that. One is setting up directory service access from your OS X client first. And in 10.4 you had a utility in your utilities folder called Directory Access. And you configure the LDAP plug-in accessible to your LDAP server.

And as long as you had a vanilla LDAP environment, you didn't really have to do anything beyond that. If you changed the schema or fooled around with some of the attributes, you may have to tweak it again. Remember the user certificate and user S/MIME. Now in 10.5, there's a new version of that tool called Directory Utility.

That's the first half of the configuration. The second half is within Keychain, if you go into preferences, in the first general tab of that, you're seeing that you could search dot Mac for certificates, or you could search your directory services for certificates. So if you do both of those parts of the configuration, you now have the ability for services like mail to pull that public certificate from that remote LDAP server.

Okay. Now what do we do about using this? Okay, let's run through just a couple of these. And help people better understand how we have approached simplifying the complexities of PKI. One thing to point out is that we, we target very much a zero configuration environment. We want to reduce that to the least amount of effort that you as user and as an administrator need to do to leverage the PKI services. So in this case, if I'm doing Mail, as long as I have an identity, right I've got the appropriate certificate there for signing of an email message.

And I've got the corresponding email address, my compose window for a new message in Mail will automatically then show or make, reveal to me the ability to sign and encrypt that message. If I don't have the corresponding identity available in any of my keychains, whether its smart card based or a file based, I'll never see that. So there's been a lot of folks that say what do I do to configure Mail to use this identity? The key is you're just entering the email address within Mail that corresponds to the identity, essentially the email signing that you have in one of your key stores.

In conjunction with that is the ability to encrypt to a user, if I'm sending one to Joe, Juser at company dot com, if my system has access to a public certificate, essentially public key there, public certificate for that user for that email address, then I will have the ability of encrypting that message, whether that certificate is locally already in a keychain or whether I have access to it through LDAP.

Related to that is when you're getting into using identities with secure web access. One of the pieces that people have run into typically has been related to some SSL VPN accesses. Of late, they've had some challenges on this. And so we want to talk about and reveal to you some of the enhancements we've done in this area.

So if you're doing client side authentication, your identity, your certificate, the first one that's valid here is presented to the, the remote server that you're attempting to connect to. And in the event that that was not accepted, right? In other words if you, if you have these multiple identities, I'd have a scenario where the server rejects it because it's not the right identity. And now I as a user need to select from the available identities that are left, in this case available certificate, right? Again, we want to get as close to zero configuration as possible.

But since you have multiple identities that have the valid usage in the scenario, you as a user would have to, need to select, so that next time we wouldn't have to reselect this. When you get into remote access, both the VPN solutions, layer two, point to point, and of course 8 0 2 dot 1 X also provide for EAP-TLS user authentication with certificates. So whether they're file based or smart card based, the services have all been there within 10.4, and again we're doing some more stuff in, in 10.5 there as well.

Now, I had mentioned a couple times about these multiple identities. That's been a challenge to some of you in environments where the remote service may not properly respond or properly respond at the lowest level of rejection, at the protocol or handshake level. And so picking of an identity has been somewhat of a challenge for some of you. So I want to show you what challenges you faced and how we've improved in that environment.

If you're picking one, you've probably seen several of these dialogues again, kind of like the Safari dialogue before. In this case, selecting from available identities for connectivity to this particular service. And I believe we've got one more there. So you can even reveal the certificate. But you've given this opportunity to select one, right? But that's only if the service that you're connecting to responded properly on the back end. And we want to review that in a little bit.

Once you've made that selection, what happens behind the scenes is that a, an identity preference is then created and put into your keychain. And remember we talked about zero configuration. I don't ever want to have to reset that every time I go to this service to pick which identity I want to use, which certificate.

So once I make that selection for the first time, I now have this identity preference added to my keychain so the next time I go to that service, it automatically relies on this preference for Safari and other services. And it transparently resolves to the appropriate one that I've selected, personal preference.

This is again that new view in 10.4, I'm looking at my certificates, I now have those three identities. What if I'm in one of those situations, again many of you I think have faced this, particularly with SSL VPN solutions. Where the proper response from the server doesn't come back.

For instance if you connect to say SSL VPN, what, typically what you're getting back is a web page that says, oh by the way you need to select an identity. Or send the right certificate. So as in a Catch 22 situation for you where it didn't respond so you didn't get a list to select from, but it kept telling you select one. So in this case, you're going to need to manually set some identities in these environments. Now in 10.5, we've given you this ability so contextual menus within keychain gives you the option now of manually setting identity preferences.

And so by doing that you can now enter that URL, and select which identity is associated with that. If you look closer though, here also gives you the ability of email addresses. So if I have multiple identities for doing email signing, I can now manually set that and mail dot app will respect that and leverage and use that identity as opposed to the first one within the system. Okay I think several of you at least that I've been dealing with over the years, have had a struggle with that because there's no manual or there's no method within mail to select between identities. Here you can manually set that in Leopard.

Again this is a, kind of a walk through entering the URL and selecting the certificate. It gives you the ability of even going back later on and editing that, changing the identity that you want to use for that plus modifying that URL or, or email address. So again a closer view of the contents.

Now, if we get to one of the, the later pieces of, of certificate approaches. And that is we always have to validate these things to be sure they're still good. It's kinda like your credit card. You know you get issued a credit card, you may use it but it may have been canceled. So they're always having to check to be sure that it's still valid.

So credit card kind of analogy here with certificates. There's gotta be some other party that we go to, to check to be sure that it is still good. And there's a couple different methods for that. The kind of legendary method is called CRL or certificate revocation list. And to help people understand this, it's kinda like downloading the phone book and then you look through the phone book to figure out whether someone still has a phone number. Whether they're still in the phone book.

And the problem with that is as your end user base grows, as your corporation base grows, so does that database as you're revoking the certificates, the identities here. And so what happens is that can grow so large that it now slows down every single process, every single transaction that you're doing that has to go out and validate the certificate. There's some access to being able to the related to the caches or in user bin CRL refresh, that actually fetches the cache. And you can even force a refresh on that as well. But that's related to certificate revocation list.

The other method is OCSP, or the online certificate status protocol. This rather than having to download the phone book, it's like calling up the operator and say is Shawn still there? Does he have a phone number? Okay, he's valid, let's go on. So the communication demands are low and as your user base grows, it's that same. So it's kind of a consistent bandwidth usage.

This is where a lot of folks are moving away from CRL and go to OCSP. Again we've got the services built into OS X. And if you're dealing with OCSP you actually have the authority information access specified within that certificate. One thing to note is if you're looking on OS X and you're looking for a process specifically for CRL you won't see it. There will be a process called OCSP, OCSPD that's doing both of those. And so it's handling CRL and OCSP requests on the client there.

Within the preferences within Keychain, and I point this out because by default these are turned off. So most environments are going to want to enable this. This is where you determine kind of by your policy how you want those, the validation methods to be utilized or to be used within your environment. As I mentioned, CRL is kind of the legendary approach to this. And there's people that are issuing new certificates using new certificate authorities of their own.

A lot of them are, are just kind of starting out with OCSP. A lot of people may be bridging between the two. You may have issued some with CRLs and now you're moving on to OCSP. We support both, even give you the ability of prioritizing which one is valid.

So when the validation of a certificate is done, it's going to attempt to follow your preferences here and in this case, I've set both of them to be best attempt, so it's going to first try OCSP. If it can't get that validation, can't get to the server, it's going to move on to CRL until I get either a positive validation of that certificate or I fail to get it. Leads back into the validation of certificate. Again, a little bit later some of my colleagues will be sharing some more information on that. This gives you just kind of a quick shot of each one of those options.

And for those of you that are building some end to end infrastructure here, there are some OCSP validators on the server both from Tumbleweed and Core Street that actually have OS X Server implementations of this. So if you're doing end to end OS X implementations, this, these are some good vendors to be looking at for their solution. So at this time, let me turn things over to Ken McLeod. Taking, taking us on with verifying the trust.

Ken?

- Thanks Shawn. Hi everybody. My name is Ken McLeod. I am engineer... Let's hear it for Shawn.

I'm an engineer in the Data Security group at Apple. We're responsible for the security frameworks and the security infrastructure that applications take advantage of.

It's kind of a hard thing to describe to people. In fact, I had a relative of mine ask me, you know, what is it that you do again? And I explained it like this. You know the commercial that we've been showing where there's a Mac guy and PC guy. And he said to me, oh yeah, I've seen that commercial.

And I said, well you know how the PC guys, there's one where he has security guy that's standing behind him and he's got the dark glasses and he's in black, and he's constantly asking the PC guy questions. And he said, yeah, I've seen that. But that's not you is it? Said, no, no, no. But what that commercial didn't show you is the Mac guy has a security guy too.

Oh really? Yeah. And you didn't see him because he was over there at the door checking everyone's ID when they came in. And that way he didn't have to bug Mac guy all the time. He was checking everyone's ID. And trust validation is a lot like that. It's a lot like checking people's ID. And when we talk about trust validation on OS X, we're really talking about getting the answers to two questions.

First question is who are you? And the second question is can you do that? Who are you and can you do that? So for example, if I'm going to a web site like Amazon and I want to buy something. Before I type my credit card number in there, I want to know who are you? I want to have some assurance that that really is Amazon. But it's not enough to just ask that question who are you. You've gotta ask can you do that? So if I go and I think I'm talking to Amazon and I ask the question who are you? And the response is Shawn Geddis, whoa wait a minute.

Shawn, I know is authorized to send email to me, but you know running a website for Amazon? Ah, I don't think so. And at this point, the Mac security guy comes out and he throws Shawn out. Sorry Shawn.

So before I got off the slide, trust validation is different in Leopard than it used to be in Tiger. And first of all I want to talk about how you knew trust in Tiger and how that worked. We use X509 certificate trust validation. And what that means is when we're trying to decide if something is trusted, they present us a certificate.

And we called that the leaf certificate because it's at the end. And we say, did anybody sign that? Who signed that? And we try to follow this chain and build a chain back until we get eventually to a root certificate at the end of the chain where we can't go any farther. And that root certificate signed itself. It has no signer. And at that point, if that root certificate is trusted, then we know that we can trust the leaf certificate.

So how do we get that root certificate and how do we know it's trusted? Well, we ship a thing called X509 anchors in the system or at least we did in Tiger with a whole list of third party CAs whose trust we are relying on, who we implicitly trust.

CAs like Verisign, Thawte and various others. And there's quite a few of those. But they all live in a file called X509 anchors on Tiger in system library keychains X509 anchors. And if, the root CA for your certificate chain was not in that file, then it wasn't trusted. It was as simple as that. There was one source of trust, the X509 anchors file.

Unfortunately there was a problem with that. A, if you wanted to trust a new certificate for your organization, you would have to get an administrator to put that into the X509 anchors file manually. And there's another problem too. When you're trusting these CAs and these root CAs, they may be issuing thousands and thousands of certificates.

And if you trust the root, you are implicitly trusting anything that that root is issuing. And you may not want to do that. In Leopard we have a new model which is a multi tiered model for trust which solves some of these problems. Well, we also use X509 certificate trust validation. We start with the leaf and we see if that chains back to maybe an intermediate certificate. Or even back to a root certificate until we get to the end.

We're saying wait a minute, this looks like the slide you showed me just a minute ago for Tiger. What's different? In this case, it's not a root that we have to chain back to. We have to chain back to what's called a trusted anchor. And once we hit a trusted anchor, then we know we can trust this.

In Leopard, we don't even have to go back as far as the root. We can say for example, this intermediate CA is trusted. Once we've decided that it's trusted, we don't have to go back any further in creating the chain. And that it limits the scope of what we have to trust.

And in fact, any certificate can be marked as a trusted anchor. I don't have to go any further. If I only care about trusting this one certificate for this one website, I don't have to trust everything all the way back to the original issuer of that certificate. And I can say in fact that they're not trusted.

So let's review. In Tiger, there was one trust model. You had to have the root certificate in X509 anchors or it was not trusted. Of course, if you were a user, you'd have to go get an administrator to set up your machine and get that in there. In Leopard there are a number of enhancement changes.

The first thing you probably will notice or have already noticed is that X509 anchors here we say are deprecated, in fact it's destroyed, its deleted. It's not there. Why did you do that you say. Well, we still provide all of those certificates that used to be in X509 anchors. They're now in a new chain change called system root certificates.

And the idea here is that system root certificates are provided by the system and you don't ever need to touch them. If you need to make changes, you can override what it is that the system gives you. And the place to override that if you want to provide for example a certificate that all users of your machine will trust, is to place it in the system keychain instead. The system keychain just happens to be available to every user of the system.

But you don't have to place it there. And in fact, it's no longer tied to the keychain that you're in, whether or not you are trusted. And that's a pretty important concept that I'll come back in a minute, but the trust of a certificate no longer, it no longer matters where that certificate lives.

So the other important thing here that's changed is the, we've introduced the idea of trust domains. Before we used to have one trust domain. It went back to X509 anchors. If it was in there, great. It's trusted. We have now the concept of a system trust domain which is all of those certificates that we provide you out of the box that are trusted sort of implicitly out of the box on the system and its immutable. That trust domain doesn't ever change. So if you want to make additions to it or say these certs I never want to trust, you'll make those changes in the admin trust domain. And that overrides the system trust settings that it ships with.

if you're a user, you have the opportunity of both overriding whatever the admin set up for you as well as what we shipped with one caveat. If you are running you know an organization or maybe a lab where you don't want people doing that, there is a way to cut that off and only have the administrator trust domain active.

So in both cases, in both Tiger and Leopard, we will chain, in order to build a chain of trust, back to a root CA, the root CA can be responsible again for issuing thousands upon thousands of certs. And if you trust the root CA certificate, you're trusting everything that it's issued and everything that it will issue in the future.

And that's a awful lot of trust to extend. So if you have a root CA or your organization issues one, its important, its very important that you have a process in place to keep the private keys when you're issuing things secure. And in fact, the certificates that are shipped in Mac OS X in the system root certificates file have to go through a process of, of web trust to certification where they can show that there is a process in place to keep that secure.

The change from Tiger to Leopard has big implications if you are issuing your own CA. And you're providing your root CA to other people. There is a dividing line. And on one side, is support for Tiger and before, on the other side is the Leopard way. So on Tiger you have to add it to X509 anchors like you always have in order for the root to be trusted. Going forward from Leopard, you'll want to put the root certificate in the system keychain instead.

So if for example you're writing an installer script, a command that's going to be your friend is user bin security. And it has a command called add trusted cert. And this has a lot of options which I'll go into. But one of the flags that you can give it is to say trust this cert in that admin trust domain and that lets it be trusted on the system.

So how does a certificate become trusted on a machine? Ideally, you don't have to do any work. You can have a zero configuration thing and then as you encounter a certificate that's new and that isn't seen before or isn't trusted doesn't go back to one of the trusted roots on the system. You get a prompt. You know is this okay? Do you trust this? You can also manually edit the trust settings of course at any time with the keychain access application.

And you can use a command line tool. Again I said, user bin security is going to be your friend here. It has an add trusted cert, but it also has a trust setting import and export command that lets you save and restore trust settings. This dialogue may look familiar. This is the standard certificate dialogue that asks whether or not you trust a certificate on Mac OS X. Safari uses this, iChat, Mail, you'll see it quite a bit. And in fact your applications can call it as well. It's in the security interface framework.

And this lets you show the certificate chain to the user and let them make a decision about whether to trust it. Now, there's one thing I want to point out with this dialogue. This check box here says always trust these certificates. And I can tell that this is a dialogue that was from Mac OS X.4 rather than Leopard.

Because on Tiger there was only the option to trust the entire chain all the way back to the root with the root being an X509 anchors. Because again remember that's the only way on Tiger that trust occurred. On Leopard it no longer has to always trust all of the certificates of the chain. And we'll see that in a minute. So in the minute is here. Let me show you, in fact, what I've been talking about, if we can have the demo machine.

I will fire up Safari here. And as I'm browsing of course I will eventually go to a site in this case Mac OS forage dot org that has a certificate that doesn't chain back, that to a root CA or anything that I've currently trusted. So when I encounter this dialogue, I can look at the certificate it's presenting me and see oh, yes in fact, Mac OS forage has a cert that is not known because it was issued by open source dot apple dot com. And that's not one of the trusted CAs that we ship with. So we have a new option here.

And I no longer remember have to trust a certificate chain all the way back to a root. So this is a common thing. I don't even have the root. I don't even know how to get a root certificate for open source dot apple dot com. But I am pretty sure that I want to go to this website and that I trust Mac OS forage dot org.

So I can say on Leopard, I only want to trust the Mac OS X forage, or Mac OS forage certificate and not anything else that issued it and I only want to trust it when I'm going to this site. I don't want to trust it for anything else. So if I hit continue, in order to make that change, I have to type in my password. And at this point, I can click on the little lock icon in Safari and examine the cert.

And I see it now tells me the certificate is marked as trusted for this account. Essentially what I've done is I have marked it as a trusted anchor. And when I'm building a certificate chain to determine trust, I don't have to go any further than this one certificate that I've trusted.

So let's look at another instance here. Here's a test server over at Red Hat. And oops, it looks like they don't have a certificate that's trusted either. So I'll look at it. And I see that they've got a little bit more of a chain going on. And this Red Hat server that I want to go to has issued by some certification authority here, Certificate Shack.

I haven't heard of Certificate Shack. I don't know what they are. And I don't know whether I want to trust them. But I do want to trust the Red Hat server because you know that is where I want to go and I want to keep going back there.

So in this case, I can decide just to trust the Red Hat certificate without trusting all the certificates or the entire chain or anything else that this Certificate Shack might issue me in the future. So I'll go ahead and do that. And we go to the, the site. And then when I look at the, the certificate, I see that there is no chain beyond the certificate that I trusted because there doesn't need to be.

So that's kind of the inline zero configuration way of things. The manual way of configuring what you'll often do is you'll get a root certificate sent to you or you download from a website for your organization. Here I've got one for Ames Lab that's a root certificate. So if I open it, it launches keychain access. It asks me if I want to add the certificate to a keychain. And remember in Leopard if we want the certificate to be seen by all users of the system, we want to put it in the system keychain. So I'll go ahead and do that.

And now I get this new dialogue. Now what is this asking me? It's asking if I want to trust this Ames Lab root certificate. Well, didn't I just put it in the system keychain? Ah! But remember it's no longer important where it lives in order for the trust to occur. The trust is separate and you have to specifically say I trust this certificate and then it can live anywhere. It doesn't have to be on a particular keychain.

So at this point I'll say yes, I want this trusted. And now if I go over and I look in the system keychain, in fact its there and its got this new little do hickey that tells me that I have specifically trusted it for all users of the system. And in fact I can go to any point and here is Certificate Shack's root and I can decide to trust it later if I want to. And of course there's a command line way of doing this.

Remember I told you that we have the security command. And security add trusted cert is your friend. In this case, there are a lot of options here if you were going through the command line. You don't have to trust at the granularity of a single certificate, but in fact you can place a lot more restrictions on it.

For example, there's a policy option that lets you say I only want to trust this certificate for SSL and nothing else. I can specify an application constraint that says I only want to trust this certificate in Safari and no other app. Or policy specific string. There's some allowed error options. But let me go ahead and show you an example of how you would use this.

I have a certificate file that I want to populate on all my lab machines at work. It's the Apple data security test CA. And so I use this security add trusted cert, add trusted cert command with the dash D option which lets it know this is for the admin domain. I want it trusted for all users. The dash K option lets me specify that I want to put it in the system keychain.

And then finally the file tells me you know which cert it is. So I'll go ahead and execute that and it just works because I have a root shell that doesn't prompt. And if I go back and look at keychain access, let's look in the system keychain. And now I see that I have this new cert in there, the Apple data security test CA, which is marked as trusted. Now there's a companion command here that you'll find useful. Security trust settings.

Now trust settings export has a couple of options for either exporting the user's domain or the system domain. And what that, this lets me do is essentially take a snapshot of everything that's trusted on my machine so I get the setting set up the way I want them and then I can replicate that on to other machines or go back to a saved, known trust setting state.

So here's an example. I'll use trust settings export, again with the minus D option that lets me export the admin trust domain. And I'll dump that into a file called save trust settings. So I do. It tells me that it was successful. Now I'll go back here and I'll make some changes. So let's, let's not trust this Ames Lab. I never want to trust them.

I'll make that change. Now we see that the trust setting is changed and it's marked as not trusted. And I don't know what this Bob's towing is, so let's go ahead and you know we won't trust it either. And now we come along later and I want to go back to the saved trust settings state.

So I can use security trust settings import to go back and take that file that I created and I could take it to other machines and set them up the same way. But I'll go ahead and blast those settings back into place. Then if I look again, we see we're back to where we were.

Ames Lab is trusted, Bob's Towing is trusted, Apple data security is trusted, and that's how trust happens on Mac OS X. But a more important thing maybe even than how they get trusted is how can you actually create them yourself. How do you get these things onto your machine? How do you issue certificates? And to talk about that, I'd like to ask Craig Mortenson to come up and he'll show you the certificate assistant. If we could have the slides back.

Wee! Yes.

- Okay.

Okay. I'm Craig Mortenson. I work with Ken on the data security team. And we work on the frameworks as Ken had mentioned. And I'm going to talk about, a little bit about the certificate assistant and do a demo of it and also talk about how to import some identities into your keychain.

Okay the certificate assistant has been around since Tiger. Some of you have probably already used it. We've greatly improved it for Leopard. And I'll show you that in a minute. The certificate assistant, it's a user friendly application that guides you through the task of creating certificates, creating certificate authorities and evaluating certificate chains. What's great about this, what's, excuse me. What's great about the, the assistant is you could create your own certificate authority and distribute trusted certificates to users. And this is done by email exchange.

This is done by email exchange between the CA and the user. And finally what I'll do in the demo is talking about doing certificate evaluations. Okay. So what's new for Leopard is the concept of signed invitations. We had invitations in 10.4, but in Leopard they're signed because when they're signed you can have the CA certificates embedded in the invitation. So for security reasons you don't want somebody modifying those certificates. So the signature will fail if anybody tries to do that.

Okay. What's also new in Leopard is the, the concept of a CA website. The assistant will actually create a website for the CA so users can go to this website and download an invitation if they haven't gotten one. And they can also download the CA certificates as well.

We also added some preset certificate types in Leopard. One, the famous one that we worked on was code signing. And some other ones that you could do are S/MIME, VPN, and SSL. And what's great about the assistant is you don't have to know the details about these certificates in order to set these up. All right, so now I'm going to go to the demo.

Okay, so we have here is a user co frag, oh boy.

So what you saw earlier was a CA that Ken was marked as not trusted and then trusted. That was called Bob's Towing. So Frank is an employee of Bob's Towing and he wants to get an S/MIME certificate from his boss to be able to sign emails. So what he does is Frank just simply launches Mail.

And we see that he's got an invitation from Bob's Towing, say that the CA is now ready to accept certificate requests. So alls he has to do is click on the invitation. And then you'll see the information from this CA right here. The user just has to click continue at this point.

So while this is happening, this is going to take a while. It says creating the key pair for Frank. The default is 2048 bit RC key H pair. And the, the CS, the CSR is actually being created and it actually was sent to Bob's Towing. So now we're going to go over to Bob.

Okay, so. Bob sees the certificate request email, says Frank has sent you a certificate request, click on the enclosure. So the CA is going to get a whole bunch of these, depending on how many employees. In this case, Bob's Towing has only one employee and that's Frank. So he's going to click on the CSR, this is the actually certificate sending request.

And all Bob has to do is just click continue. Because we're, we only have one CA on this machine. And if, if Bob wanted to actually override the defaults and say well, I'll, I'm going to make him an S/MIME certificate and it's going to be able to do code signing and a bunch of over things, but we're not going to do that for now. We're just going to do the demo for S/MIME.

Okay, so what we have here is the email that's composed with the certificate that was just created. And Bob just sends it off. Okay. And then in the end of the certificate assistant you'll see this is the actual certificate that was created for Frank. And that's the one that was sent off. So now we'll go back to Frank.

And we got the email back from Bob and it says here is the certificate. Click on the enclosure. Goes into the log in Keychain. And you can see there is Frank's identity. So now just to show how it works here, if Frank wanted to send an email, you can see right now, now he's able to sign his emails. So Frank's all set.

Okay so now I'm going to show you how to create a certificate authority. We'll go back to Bob here. Now Bob's already created a certificate authority, but we're going to just go ahead and create another one. I'll show you how we create a root. So the certificate assistant is invoked using keychain access. The other ones were just simply files, you click on it, it launches the assistant. But this is like the main entry point for it. So we're going to create a certificate authority.

We're going to call it Bob's certificate authority. The other one of course was called Bob's Towing. It's going to be a self signed root CA. By default it's going to be creating, going to be distributing S/MIME certificates right here. And the, the default key pair would be for this CA would 2048 bit RSA. If you wanted to override these defaults, you can do that. But we're not going to do that for now.

Here's where its creating that CA website that I talked about earlier. And this is a button where you can actually look at the CA website that was created. Okay? So this is automatically created. On this case its on Bob's iDisk, but you could specify an alternate location for this.

And so here it's just you can click here to download an invitation. So if the user hasn't gotten that invitation email from Bob, they can simply go to this website and download them. And they can also download the CA certificates that make up the chain. So and once you download those you can install them with keychain access.

Okay, so now, now that we've created a root, oops. We are going to create a intermediate certificate authority. So we say create certificate authority again. In this case we're going to call it

Make it an intermediate. And again, we'll make this one distributing S/MIME certificates. Now in order to be an intermediate CA, it has to be assigned by another CA or the, in this case the root. So we'll just choose Bob's Towing. And we can actually see the, the Bob's Towing certificate right there.

It's creating the CA website again for this one. And you can actually see the actual certificate that was created for this CA in this, at this point. You could also, this is where Bob would be mailing the invitations. So if he clicked mail invitation, this is one we saw earlier and so we can type in Frank or any other people that he wants to advertise this to and sends it off.

Okay, so now what I'm going to do is show you how to import some identities. I've got some identities in my documents folders that are PKCS12 files. And so we're going to import Alice. And it's really simple. It's just, you click on the file, specify the keychain you want it to go into, in this case the log in keychain.

Since it was wrapped as a P12 file, it's got a password for it. And you could see Alice has been imported into the log in keychain. Okay so now we've got, you can see I've got another one here called Chris. But we're going to use the security import command.

Oh boy.

Okay. So here we're using security import. Chris dot B12. We're going to put into Bob's keychain. We're not going to put it in the log in keychain. And then here in this case the password is Chris. And it said it, it already imported the identity. So if we go back, we see Chris.

So that, those are just two examples of how you can import some identities. It, you can import HM files and all kinds of documents just by double clicking on them in the Finder. Okay, so that's it for the demo. And now I'm going to ask Shawn to come back up.

Thank you Craig. So to just kinda wrap this up as, as a summary, hopefully we've given you a much better insight, many of you even on 10.4. But really better understanding what identities are, how you can manage them, doing the obtaining of them, use, utilizing them, even issuing the identities themselves. And understanding the trust model. Remember as, as Ken mentioned there's a huge change in the trust model going from 10.4 to 10.5.

And hopefully you've seen as well as we've gone through this process, both from the application side, from the certificate assistant side and even the trust model that we're working very hard to make PKI, which is a very complex service when you're dealing with all of these different components we talked about early on.

We're really working hard to make that an environment that just works. Again the, the zero configuration approach for the management of these, these very complex services. So with that said, there's a little bit more information depending on the where you're coming from. If you're a developer getting into the security services like certificate and PKI side, Craig would be your best, Craig Keithley would be your best contact from the developer side. And if you're on the enterprise side, government, commercial space, I largely kind of interface with a lot of those folks in kind of the deployment, kind of the management of that.

So depending on where you fit in this space, two contacts. Some of the other areas that give you some really good information is those of you that are, are going to be issuing your own certificates, creating your own certificate authority, look at Apple's root certificate authority website. You can see a lot of the appropriate information and background on, on what Apple's done as well. And of course since this is all security related and it fits into the CDSA deal, being on the CDSA mailing list is a great resource for many of you.