Directories and PKI

1. Directories and PKI Basic Components of Middleware

2. The Context • Institutional business is increasingly complex • Requires e-automation • Independent systems must interoperate • Requires standards and “trust” • Human resources are increasingly scarce • Requires efficiency and distributed responsibility • Some day much of our world may work this way • E-commerce and the information economy

3. We take a lot for granted today • Email used for business transactions(!) • No “validation on send” for email • Electronic documents used for contracts • What proves they haven’t been changed? • Which copy was accepted by both parties? • Even the network is run with loose “trust” • Domain name system • Routing protocols • IPSEC will fix this!

4. Middleware • A set of cooperating infrastructure services that provide other support a variety of applications • Some components include: • DNS, time, message queuing and forwarding • Authentication • Directories • Portals • Business workflow and policy services • Electronic notary and archive services

5. Credentials are the cornerstone • Management of access begins with sureknowledge of the entity requesting it • A digital credential binds a token to known entity • Who issues such credentials? • Required trustworthiness depends on application • Credentials alone are not enough • What does it mean to ask “Who is it?” • The answer depends on context

6. Directories are the glue • Directories will store most of what we need to know about credential holders • Attributes, e.g. characteristics, roles, affiliations … • As critical as the credential itself • Must be reliably populated and maintained • Some information is only meaningful locally • Some must be understood more broadly • Directories will also help locate resources

7. Distributed Systems are the Blocks • We’re not going to (re)build monolithic systems • Systems need to exchange information reliably • Business XML … • … validated with digital signatures • … encrypted when necessary • Systems need identity too • E.g. “server certs” • Portal as proxy for the User…

8. Portals provide views • Personalization is the basic idea • Could be based on roles and affiliations • Can support scalable & timely access management • Must render information from various systems • Data exchange standards, etc. • Must ‘speak for the User’ in accessing systems • Requires a digital credential to identify itself

9. Digital signatures and data security • “Signature” binds an entity’s identifying mark to specific information • Paper does this in the physical world • Asymmetric encryption does it in the e-world • PKI provides the basic elements • An encryption key known only to the signer • A decryption key tied to the same entity • By reversing the use of the keys we get data security

10. Automated Workflow • Ties together systems, Users, and business rules • Should be based on roles and responsibilities • Could streamline transaction oriented systems • For example, procurement: • Originator digitally signs request, fwds to AW svc • Budget authority adds fund info, countersigns, fwds • Purchasing agent reviews and feed into accounting & asset management systems and e-commerce agent • E-commerce partner submits invoice w/e-signature

11. Some current activities • CREN Higher Ed root CA • Educause Higher Ed Bridge • Middleware Activities for Education (MACE) • Sponsored by Internet2 • HEPKI • Technical planning for PKI • Certificate Policy and Practices definition • Shibboleth • PKI WG under Net@EDU

12. Shibboleth • Leverage current campus authentication systems to enable access to external resources • Complimentary to PKI • Will foster development of needed infrastructure • Directories !! • Attribute Authority server • Manages attribute release policy • Standard language for attribute assertions • Intended to interest content publishers (at least)

13. Further info • http://middleware.internet2.edu • david.wasley@ucop.edu • Join the working groups!