Good morning and welcome to the session on certificates in Mac OS X. I'm Craig Keithley. I'm Apple's security and cryptography technology evangelist. Today we're going to talk about, to some degree, our common data security architecture with particular interest on what we're doing to improve access to certificates. There's a number of new APIs that are coming in Jaguar that will make this easier. There's changes to Keychain. And as I said, we're going to improve the certificate functionality. To start that off, I'd like to bring out Ken McLeod, a senior software engineer in the data security group. Thanks very much.

Thanks, Craig. The session is a little bit badly named. It's not just about certificates, like as Craig said. It's also going to talk a little bit about keychain and where we are with that and how they tie together. And we'll talk a little bit about things like access control on items in your keychain, access control on keys, and trusting, being able to trust a certificate and how you do certificate management.

Oops. So I'm going to start off, first of all, with an overview of CDSA. For those of you, hopefully, who were in the last session, some of these things may be familiar concepts. Then we'll spend some time talking about the kind of functionality that's provided by the security framework. This is the open source framework that's part of Darwin, where all these functions sort of live. And, of course, we'll talk about certificates and how you use them to establish trust and how you can store certificates in a keychain and the integration between keychain and certificates.

I do have to press this hard, don't I? So the common data-security architecture is something that's been part of OS X since day one. It's the foundation on which all of the security services are built. And it's a modular architecture, which means that the functionality that's provided can be just plugged into the backend of it.

There are four basic types of modules that plug into CDSA. A CSP, or cryptographic service provider, provides all the encryption functionality, so all the encryption algorithms live there. Data libraries give you all the data storage functionality. They act as your database API. A certificate library is a module that knows how to parse certificates and pull them apart.

And a trust policy module is the code that actually lets you make decisions involving certificates. For example, would I trust this certificate to do-- SSL and make an SSL connection versus would I use the certificate to encrypt something? So all of this functionality lives under an umbrella set of APIs called CSSM, the Common Security Services Manager. And the neat thing about this API is that once you've written code to it, you can replace any of those modules underneath it without affecting your code.

So you don't have to rewrite your code in order to take advantage of, for example, if a CSP is replaced and it provides a stronger encryption algorithm, or if a DL is replaced and it suddenly gives you access to LDAP or, for example, storing things on smart cards. So the API sort of transparently lets those things happen under the hood.

So the API is that bar that runs across the second from the bottom layer, the CSSM bar. The plugins go underneath that. Above CSSM, we've tried to provide some higher level layered services that make these CSSM things easier to use. So, for example, we have a certificate API that lets you deal with certificates in a little bit easier fashion.

In the earlier session, Murph talked to you about the SSL API, secure transport, that's also built into this. So, at the top level, applications have their choice of whether they want to use some of these higher level layered services or whether you want to drill down and get into CDSA itself and use the CSSM APIs. You have your choice there.

Disk copy, for example, uses--

So why would you use CDSA at that level? Some of the things that are provided there are basic building blocks of encryption. It allows you to generate keys, both symmetric keys and a public/private key pair. If you need to do encryption, the earlier session had an example of how you would use CDSA to encrypt data. CDSA provides a whole bunch of algorithms, the Advanced Encryption Standard and a number of others. There's far too many to list, actually. It lets you digest data or hash it using the standard hash algorithms.

It provides data storage and retrieval, easy APIs to have a place to store and retrieve data. One really interesting area of functionality in CDSA that Perry is going to talk to you about a little later is the whole area of access control. You can specify when items can be used and have a very fine level of control on that.

The other area, of course, is the ability to parse certificates. Apple provides a X.509 certificate parsing library, but it's by no means limited to that. Certainly the architecture allows for any kind of certificate module to be plugged in. This is just, by the way, a subset of the things that CDSA can do.

Oops, skipped to him. So on Mac OS X, all of CDSA is implemented in a framework called the Security Framework. It's the place where you would go to find the CSSM APIs and all of those interfaces. And it also provides all of the new higher level layered service APIs such as secure transport and any of the functionality beginning with SEC, the SEC prefix APIs that I'm going to talk about a little more in detail.

At this point I have to give a caveat. Those APIs, I don't believe, are on the CD that was handed out at the conference. I don't think they made it in for that version. But if you look in the security framework, you'll see the CDSA APIs and then you'll see a security.h header which lists all of the other headers that will be there very soon. The security framework is part of Darwin and is open source, so you have the ability to look at all this code.

One of the things that we got as feedback, certainly in previous years that we've heard, is people want the ability to have factored out user interface. So if their code, for example, needs to be a faceless daemon or you don't want to link your application with all of the UI frameworks and just keep it lean and mean, we now provide the ability to do that.

So what we're calling the Sec APIs, security APIs with that prefix, are actually patterned after the core foundation API. If it looks familiar that's because this is the model. And in fact, all of the objects that you deal with when you're dealing with the security APIs are CF objects. So keychains, keychain items, certificate wraps, all can be dealt with in a core foundation way.

You can use core foundation interfaces to retain them, release them, you can store them in a CFArrays and so forth. Like Core Foundation, if an API has copy in its name, you know that it's handing you back an object that you need to release. So a copy, a sec copy, whatever the object is, you'll have to call a CF release on it when you're done. If it's a sec get some kind of object API, then you don't need to release it.

When you're searching for security-related objects, the APIs will look familiar. They'll be Sec, whatever the object is, Search Ref, and there'll be a Search API that will give you back whatever that kind of object is you're searching for. The Sec APIs also provide the ability to drill down below them to get at some of the underlying CSSM or actually CDSA objects.

One of the hardest parts of using CDSA for most people is actually figuring out how do I get a handle to the CSP or the certificate library. Those things are sometimes a little bit difficult. There are convenience APIs at the Sec layer to actually hand you back those objects.

So the Keychain Manager in Carbon provides a level of functionality that includes automatic user interface and sort of high-level convenience calls wrapped up in one package. The SecKeychain APIs provide the same level of functionality, but they've been factored differently. So you can call them and not have to worry about linking, as I said before, with UI layers.

There's also a sort of expanded--it's a superset, actually, of what the Carbon Keychain Manager calls "provided you."

The SecKeychain APIs expand on the Carbon Keychain Manager APIs and add more parameters so that you can specify all the attributes of a keychain item. Also, they provide the ability to let you specify the access control. So when you create an item and store it in a keychain, you can specify a list of trusted applications that have access to that item.

In the X.509 world, these certificates can form a chain, and at the end of the chain you have a leaf certificate, which just certifies whoever's public key that that certificate is issued to. At the other end of the chain is the issuer, the final issuer, the root certificate, which signs itself and sort of certifies itself.

And then it can sign intermediate certificates all the way down to the leaf that form a trusted chain. There can be self-signed certificates which certify themselves. You can have a root certificate that, for example, is a certificate authority. VeriSign, some of these other large certificate authorities are familiar, but you can also set up a certificate yourself that you have trust in.

Generally, X.509 certificates are used for things like making secure connections via SSL when you're doing, for example, an e-commerce transaction. You connect to a server that has an SSL certificate, and that forms the basis of a secure connection. And they're also used for SMIME, which is the standard for secure email and encrypting email. So with that, I'd like to introduce Perry 'the Cynic' Kiehtreiber, who's going to get more in depth and tell you what is available with certificates and trust. Perry.

Somebody came after all. You look kind of empty there for a while. Oh yeah, certificates. Well, as Ken told you, there are a number of different API objects in the sec layer that we made. But certificates certainly are sort of... those in keychains are the most important ones, the ones that you're most likely to get in contact with. For now, a sex certificate ref in the style of Core Foundation represents an X.509 certificate. In the future, it may also be able to represent others, but 509 is what we do right now.

There's a couple of different ways you can get one. If you happen to have a certificate lying around as a data blob, you can just call a creation function to make a sec certificate from that blob. I mean, certificates are flat, unstructured data. You can search for certificates in your keychains, in the user's keychains.

In any keychain, you'll care to name, but by default, in the ones that the user has set up. Certificates can be stored in keychains just fine and searched by the various attributes that they have. And sometimes you use API functions that, as sort of a side effect of their operation, produce certificates that may be of interest to you. SecTrust is one of the examples we'll look at a little bit later.

So once you have a SEC certificate, Raph, what do you do with them? You can use them in some of the higher level APIs. Certainly secure transport is one of the better examples since SSL is based on exchanging information during handshake based on certificates. Sometimes you need to feed certificates in and sometimes it can hand you back the certificates that it got during its negotiations.

SEC trust is another example because one of the major things that you do with certificates, arguably, essentially the only thing you do with them is to use them to establish whether to trust someone to do something. And certificates are also part of what we call identities. We'll talk about that a little bit later. Identities are essentially the personalities that a user, or for that matter, a program has.

What else can you do? As I said, you can store them in keychains, in one keychain or in any number of keychains if you prefer, and you can search for them based on, you know, issue and other attributes that they have. Gee, there's SecTrust again. And we also have a set of UI APIs that allow you to display certificate chains to the user, either because you built them, they work, and you want to show the user and say, "This is what you got," or because something went wrong and you want to show the user the chain as best as it could be built and say, "This is what's wrong." Oh yeah, certificates have absolutely no access control. And that's okay, because they are public things. They contain a public key, and they contain some other attributes that are signed with a private key. The private key of the certificate that certifies this one.

And so they are in a fairly interesting way self-verifying. In other words, you can hand them out. You don't have to worry about protecting them. You don't have to worry about keeping people from using them, because the only use for a certificate is to verify something. Some operations, some relationship. And for that, they can't be faked if you follow the rules.

SecIdentity. Well, as I said, identities are sort of the online representation of a user identity in the public key sense. A SAC identity consists of three parts: a public key, a private key, and a certificate. The public key and the private key, of course, go together. They're an asymmetric key pair. And the certificate is a certificate that certifies the public key.

Now, these are not necessarily stored in one blob somewhere. They are actually stored separately in keychains. Now, typically, they'll go into the same keychain, but that's not technically required. You can actually store, say, the public key and the private key in different keychains, which sometimes makes sense if you want harder, better access control to the private key.

Access control, I said, certificates don't have it, public keys don't need it, but of course the use of the private key, which you would use for signing and decrypting, is controlled. And so, to the extent that there is access control for a SEC identity, it is the access control of the private key that's part of it.

I can never avoid giving good advice. It's sometimes very tempting to do your own security in your program, your own access control to these things. And I would really like you to try not to do that. Because any mechanism you put into your own program will only work in your own program.

And if The private key, the identity, it's actually stored in a keychain. All that a bad user has to do is use a different program to get at it. If you're using the mechanisms that are built into the CSSM stack and into these functions, they will apply no matter how a user tries to get at these. which is a heck of a lot better. If you need interesting ways of protecting access to your items, we'll talk about SEC access a little bit later, which should give you more than enough rope to hang yourself in really interesting, twisted ways.

Alright, SecTrust. What's that for? SecTrust is... A little bit unusual in that it doesn't really represent a data object as much as an operation. The primary thing you do with certificates in the X.509 world and for the most part all the other worlds too is you are... Trying to find out whether a certificate that somebody handed you really shows that you're supposed to do something for him.

And the way this typically works is first you check to see whether you can actually build a certificate chain from that certificate to an anchor, a root that you trust. And then you look up somewhere in some database to see whether, well, now that you've convinced yourself that that certificate is valid, whether this really means that you're supposed to do what the guy asked for.

So there you have the steps. You have to validate the certificate. If it's not cryptographically valid, then obviously you can't trust it. And if you can convince yourself that it is valid, then you look it up in a database to see if the user actually said you should trust it for this particular operation or not.

That sounds pretty complicated. It is pretty complicated. So what we've tried to do with the SecTrust object is to make it, well, as painless as possible is what I like to say, but as little painful as possible is probably fairer. Those of you who've tried to actually write code to do this game, certificate chain validation and trust management, know that it's not easy. And it gets really complicated really fast. So keep that in mind. We're trying to make this as easy as we can for you, given the complications.

So, as I said, SecTrust is a workflow object. So rather than representing something on disk, it represents an operation in progress. You make a SecTrust object, you stuff whatever parameters and arguments and options you need into it, and you tell it to evaluate, and then you look at what it can tell you about the result, about what happened when it tried to evaluate.

What can happen when you evaluate a SEC trust? If you're lucky, it actually worked, meaning the certificate could be validated as part of a valid certificate chain. And we looked it up in the database and we could find out that the user said, "Yeah, go ahead, do this." Or he could have said, "Oh, no, don't do this." Or he could have said, "Um, ask me about this, because I want to decide each time separately what I want to do about this." Or, well, the user could just never have said anything about this particular situation. So that's the four valid user choice outcomes.

But then again, maybe it didn't work. And if it didn't work, we actually helped you distinguish between two different major classes of failures. Sometimes it sort of almost worked. You can just almost feel that if only this little thing here or there could have been changed, then it would have worked. For example, you can build a certificate chain, it works just fine, but the root is not trusted, the root is not an anchor.

Or you try to build your certificate chain, and, well, you're missing one in the middle. You just can't build the chain. But if only you could find that certificate, then everything might be fine. We call those recoverable errors. So if SecTrust Evaluate tells you that you had a recoverable error, then depending on what kind of a user you have, you may either just say, "Well, this didn't work," and go away, or you may want to bring up UI using a UI function that we have provided for you that will essentially present to the user a certificate.

So you can compare the certificate chain as it was built with little annotations telling him what's wrong. And you can give the user the option to try to fix things. On the other hand, sometimes things just don't work out at all, and we call those fatal errors, basically.

If the certificate is corrupt on its face, then there isn't really anything you can fix about it. It's just broken, you know. You hope that it was just a bad download somewhere. You hope it's not an attacker trying to fake you out. But in any case, it's broken. That's fatal.

Whether you have success or failure, there is a raftload of additional information you can get out of SecTrust once it has evaluated. If you are interested in this on the technical level, you can retrieve the certificate chain as SecCertificates, of course. You can get information about each certificate as to whether it was valid or why it wasn't valid.

And you can get some other sideband information. Whether you're actually interested in this depends, again, on what you're planning on doing. If you are dealing with a naive user and this isn't really your main job, you're just using this for trust validation, you probably just want to ignore that information, and that's fine.

If you think you have an expert user who wants to know about these things, call the UI function, present the result to the user. That's probably the easiest thing you can do. If you're writing a program whose main job in life is to deal with certificates, then you may actually want to walk through these results yourself and try to figure out what's going on. So, it depends on your purpose in life, or your programs at least.

After you make a SecTrust object, what are the parameters you can stuff in there to change the way it works? The first and probably most interesting thing is a policy. Policies are sets of rules determining exactly when a certificate chain is considered to be valid. Different scenarios have different rules. For example, SSL and SMIME have different rules on exactly what constitutes validity. They're not dramatically different, but they're different enough that you have to tell the system the difference and tell it exactly what you want.

Some policies have policy parameters that you have to pass in. For example, SSL requires that you specify the URL of the server because it actually needs to compare the URL embedded in the certificate against the one that you actually connected to. And if those mismatch, then technically your certificate is no good, even though many browsers I could name just don't care. Another thing you can do if you have additional certificates that could be useful to build the chain, then pass them in. That's strictly for the use of the system as it sees fit, so pass in lots of certificates if you think they can be useful.

In some situations, like SSL, you actually get certificates out of the negotiation process and you want to pass those in, obviously. You can also specify keychains to be searched for additional certificates. Now, by default, you get the default search list of the user, which is almost always the right thing.

Basically, the user has a preference of its keychains, his keychains, her keychains, whatever. Sometimes you want to change that. Sometimes you want to just not search those, and so you pass an empty list in. Sometimes you want to add a special keychain of yours that the user doesn't normally deal with. So you can do that.

And while we provide a default set of anchor certificates, trusted roots, if you have your own, you can certainly add it and make it also be trusted as a root of a certificate chain. You do that either because you're a little bit of a hacker and you made your own, or because you are part of an organization that has its own certificate chains. And you want the corporate certificates to be trusted, too.

All right, so second step in this game, as I said, after you've verified that the certificate chain works, is you look up the certificate and the operation in some database. Well, we have a database for you, and it's called the User Trust Database. It's actually stored in the user's keychain, so it's a per-user kind of thing, since obviously every user has a different idea of who you want to trust.

And for the most part, it tends to be handled pretty much automatically for you if you're using the UI functions. Basically, You start a user with an empty slate, nothing specified. So any SecTrust evaluation comes out with "I don't know, user didn't say," which most programs will map to "ask the user." So you ask the user. And the user, in addition to saying, "Yeah, go ahead," or "No, don't do that," can, in that UI, basically specify what he wants to happen the next time.

I mean, this is the classical, "Well, yeah, from now on, always," or "From now on, never," or "Well, ask me again next time." So in simple scenarios, you don't actually have to worry about this particular slide, because the user will just be able to fix his own database just fine.

If, for some reason, you actually need explicit access to it, you can, and that's called the SecUserTrust functions. It's basically just a get function and a set function. You specify a certificate. You specify a certificate. You specify an operation code. And that's all there is to it. The values associated with each certificate and operation are of course, you know, yes, no, ask, or not specified, the same ones that we've talked about before.

The Apple CDSA framework contains libraries that allow the interpretation of X.509 certificates and provides examples of common ways to use these new APIs to provide additional value to your customers. Ken McLeod, Perry 'the Cynic' Kiehtreiber Here's just an example they slipped in for how the UI looks like for managing these.

If you need to explicitly manage them, but all you need to do is have the user edit the setting for a particular one, you can actually call a function that just puts this up for you and asks the user so you don't have to do your own UI.

Enough about certificates. Access control is so much fun. It's basically about keeping people from doing things. And you get paid for that, too. CFSM, which in this session and the previous one everybody has been happy to tell you, is a really complicated beast. It's got very, very many functions that all have to be called in interesting ways. And so of course it's not surprising that it also has an access control facility. That one is based on access control lists, ACLs, as we all call them.

This is pretty much the minimum you need to know. So let's see.

We're using, CSSM uses, a lock-and-key approach. Basically, you set up a type of lock, and the user has to provide a corresponding key to unlock, and thereby permit an operation. The locks are called subjects, that's just what they're called, and the keys are called samples. Access control lists are attached to keychains, to keys, and to some items in keychains.

It doesn't matter what they're attached to. The mechanisms are all the same. So the rules for setting up ACLs, evaluating ACLs, determining whether an operation is allowed or not, doesn't depend on what kind of object is being protected. That's good. It means you don't have to worry about details here.

Each access control list maps operations to subjects. Basically, for each operation, you can specify the lock, the protection, that needs to be opened up in order to perform this operation. So, for example, you could theoretically say things like, "In order to encrypt with this key, you need to provide this password. And in order to decrypt with this key, put up a dialogue and ask the user." And, by the way, this application over there is allowed to sign with this key without having to do anything else.

That would be one ACL configuration. A little bit strange, but certainly possible. In addition to subjects and access controls for each operation, there is one special entry called the owner, which is the permission to actually change the ACL itself. So access control lists are protected by themselves, by the same ACL mechanism.

There are theoretically an unlimited number of different subject types because you can write your own. CSSM specifies about a dozen types, of which I think we've implemented four or five, plus three or four Apple-specific ones. But the most important ones that you will come across are user confirmation, which is basically put up a dialogue and ask the user whether it's okay. You have application identity, which basically means if you happen to be that application, you're allowed to do this. And simple passphrases, which have nothing to do with the passphrases to keychains. They are extra passphrases you can put onto items to guard them.

Well, how simple can we make this for you? We have SecAccessRef objects. A SecAccess object is all the access controls on an item. It basically represents the entire ACL complete with owner and all the trimmings. So, as long as you manipulate SecAccess objects, at least you're not going to drop half of the information somewhere along the wayside.

SecAccess objects are not tied to a particular item. They are valid on their own, which means that you can derive them from one object and apply them to another, or you can derive them from an object, change them, and reapply them to make a change, or you can make them from scratch and then apply them.

The two major ways of making them are either retrieving the current access control configuration from an item, and again, it doesn't matter, it can be a keychain, a key, a protected item in a keychain, or you can create it from scratch and then populate it with your information.

The uses are you can apply a SecAccess to an item, which essentially changes its access control configuration to be like the SecAccess specifies. Or you can pass it to an item creation function, which will make the configuration specified by the SecAccess to be the initial value of the access control for the item. And by retrieving it from one item and then applying it to another, you can copy access controls. So you can essentially say, make this one protected just like that one over there.

You need to know a little bit about what's inside of a SAC access. Each SAC access contains one or more SAC ACL objects. The name is probably not optimal, but that's what they're called right now. So you have SAC ACL ref objects that you can retrieve from a SAC access ref. And basically, each SAC ACL applies to one particular operation. So you can have one for encrypting and one for decrypting, or one for inserting and one for deleting, or whatever your pleasure is.

Up to this point, this represents the full complexity of CSSM. You can have some hacker made up a really, really complicated access control list for an item. That works just fine because the machinery that's actually implementing this stuff is completely general and fully functional. The problem comes when you're actually retrieving this from an item and you want to understand what this access control list means.

Because if it's really complicated, you'd actually have to understand all of the CSSM ACL machinery, which most of you probably want to avoid. So what we've given you is a small subset that just happens to include all of the ACLs that are being set up by default by our system. So as long as you don't have a hacker doing really interesting things, the simple subset of access control lists will work just fine for you.

We call those simple, and there is a function to take the simple contents out of a SAC ACL ref. And as an error, you'll get back if the contents happen not to be simple, in which case, depending on your purpose, you can either give up or you can mark it as being complicated and not understandable. Or, well, whatever else you want to do. Simple XACLs, simple access controls for an operation, simply consist of a list of applications that are allowed to do the operation without any further restrictions.

And if the requester happens to be not one of those applications, then the user will be prompted. Now, most of you who have used OS X have seen this happen. If you are trying to access an item in a keychain, you tend to get this dialogue that says, you know, typically what application so-and-so wants to do this and that operation with item so-and-so.

Do you want to allow it once? Do you want to allow it always? Or do you want to deny it? That's exactly what a simple ACL is. Basically, you get the dialogue if none of the applications in the list happens to be the one that you're running to make the request.

So the options you have in terms of information is you have the item name, which is actually stored as part of the ACL. That is the name that guides the item so-and-so in the dialog. And you have a couple of options that's new for Jaguar. Specifically, you're going to have an option in Jaguar to either just have a dialog that lets the user say yes, no, always, or you can force the user to re-enter the keychain passphrase. A lot of people have asked for that, and so we've put it in. It's an option.

Let me just emphasize that one more time. If you are running into a complex ACL, which simply means a not simple one, try to leave it alone. Don't just go, "I don't understand this," and replace it with something you understand. In particular, you can copy complex ACLs from one item to another just fine by just retrieving a sec access from one item and then applying it to another. That works. You just can't decompose it with the simple API because they're not simple.

Oh my, summary already. Okay, well, most of these sec functions are new. They're all new for you because they were private last time around. That means that they're not there in 10.1. And if you want your code to work in 10.1 and 10.2 together, unfortunately, you can't call them. Well, that's what happens with new APIs. You're pretty much stuck with the KC layer if you want to write 10.1 and 10.2 compatible code, unless, of course, you want to have different code paths.

They're sitting in between the old KC layer, which is part of Carbon, always part of Carbon, and the CSSM layer, a little bit more towards the top than the bottom. And that's probably how you should think of them. They are easier than CSSM and more flexible than KC. We hope that for many of you it's just about the right level of abstraction and just about the right level of simplicity. But let us know. We're certainly always interested in finding out where you want to go.

And nobody forces you to actually use them all, really. I mean, there's no code in there that checks to make sure you call each of them at least once. So, pick the one that sounds like what you want, call it, ignore the rest, and, uh... If you know a little bit about CDSA, whether that's because you like it or because somebody forced you to, you are definitely welcome to mix and match. For example, Ken talked about the bridge functions. Basically, for each abstract API object in the sec layer, sec_keychain_refs, sec_item_refs, sec_key_refs, sec_certificate_refs, there are functions that allow you to retrieve associated CSSM objects.

Often, if what you're trying to do isn't quite covered by the Sec APIs, you can get away with 95% Sec code and one of those bridge calls and one or two CSSM calls, which is a heck of a lot easier than doing it all in CSSM. So don't think of this as all or nothing. Think of it as sort of a flexible continuum that you can walk around in.

Technically, you can call KC APIs, use the resulting handles in Sec APIs, get a CSSM handle, do a little bit of management down there, move back up, use Sec. That actually works. It's all for you. Try to use it. And, well, avoid micromanagement. I said this a few times already, but let me say it one more time.

We've put facilities in there, access controls, certificate management, trust management, that we think are about right as a shared facility in the system. Every time you go off and you do your own in your program, your program becomes a little bit more different from all the others around it.

Maybe right now that doesn't matter because you're the only application that's going to do this particular thing. But every time you go off and do your own thing, rather than relying on trust management, certificate management, identity management that we provide, you'll get farther away from the shared system facilities that make your program work well with other programs in the system.

There are situations where you have to, because what you do is just different or weird or special. But before you just go off and write your own code to do this stuff, think about it a little bit. See if maybe what you want is something that's more like a standard, but not something that's just a standard. Just a variant of the normal behavior. Your users will probably thank you in the end. There's Craig again, except his email is missing. But I suppose you're supposed to send him email. Another slide. Ah, there he is.

Well, we're one session further down the roadmap. You've already missed 1.13 if you weren't there. That was before now. And you've suddenly missed authorization. CF Network is of interest to you if you're doing things like web servers and stuff that does networking. Its only connection to security really is if you're using SSL. CF Network, if you do HTTPS, is using secure transport. Kerberos, if you're really interested in ways of authenticating users, that might be of interest. And of course, if you thought this presentation really, really, really stinks, then go to the feedback forum and tell us about it.

More stuff, I mean, go to developer.apple.com and you can probably find most of this. And, yeah, this is all open source. Well, no. Not the UI stuff. But the UI stuff is, you know, Aqua, liquidly, soft, and all that. That's OS X. But everything underneath is Darwin. So, go, take a look. If you're wondering how this all works, take a printout to lunch. Have fun.