UCCAP, Limited Production System Working Details

Contents:

Strategy
LPS Components Being Pursued at UCOP
Schedule, Work in Progress
Caveats
Assumptions
Issues, Open Problems, Random Questions
Miscellaneous Resources

• The Authentication Working Group (AWG) is working on some major serious issues and intends to issue a report.
• UCOP is working on the 4 LPS components further described below. Some could be in test production as early as June 1998, given successful resolution of open problems and/or appropriate compromises.
• Campuses. UCSD and UCLA have projects with target schedules; UCD is ready to issue certificates when there is an application ready to use them. This needs to be further refined so the UCOP and campus efforts coordinate and leverage each other as much as possible.

LPS Components Being Pursued at UCOP

• University Directory (UDir, formerly DDB)
  A major project to provide a directory which (eventually) lists every person ever associated with UC.
  A "Day 1" UDIR has been designed with the limited objective of making NetID's for (most) employees available. A strategy/schedule for students is being devised.
  More UDir details.
• PKI - Public Key Infrastructure
  The PKI will issue/manage UCCerts for people and applications.
  Technology/vendor for the LPS is Netscape (which is free) for the initial rollout. If campuses intend to use a different technology/vendor, we should be careful to check interoperation.
  Longer-term, UCOP is assembling a list of requirements/desiderata. This might lead to an RFI/RFP for future technology/vendor.

  We envision a hierarchy (schematically):

  			   |--campus1CA
  			   |
  			   |--campus2CA---|--subsidiaryCA1?
  			   |		  |
  			   |--...	  |--etc...
  	RootCA.ucal.edu ---|
  			   |--campus9CA
  			   |
  			   |--ucopCA
  			   |
  			   |--(possibly labCA's eventually...)
  		

  Note - one main CA per campus! We expect campuses to certify subsidiary CA's, but policy needs to be developed.
  We are working on certifying RootCA.ucal.edu with some outside authority (so that users don't get "do you trust this certificate" warnings from their browser), but may not succeed.

  A draft policy exists. It includes a certificate payload

• Authorization infrastructure. An prototype attribute server is being constructed. See
  Functional Specification for UCCAP Attribute Server and Attribute Query Protocol - a draft spec for review - and
  The Limited Production System: Authentication and Authorization

• MelWeb - an application which will allow a person with a browser and a UCCert to use Melvyl from any location. Enabling Melweb for Certificate Authentication (Draft 4/10/98) gives an overview of how it will work.
• Employee self-service
  Employeed self-service is a major project and will go on over a long period of time. See ESTF Report
  Short-term, a web package ( Online Enrollment) which new employees can use to specify their benefits package using the web has been selected to be "certified" and it has been in production since Sept 1998.

Schedule, Work in Progress

• April 30, 1998 - Production Day 1 UDir available (caveats - PPS/IVR data only (but not labs), no real-time access, just daily feeds, ...).
• June sometime - a real user accesses MelWeb using a certificate issued by the UC PKI.
• September 1998 - Benweb went into production.

Currenty, work is going into:

• An RFP for CA technology is being drafted by UCOP. Campus input will be sought.
• Policy is being worked on.
• Creating the UC PKI - getting campus CA's registered, etc.
• UDir, Day 2 - student data, additional fields, etc.
  see University Directory Data Element Documents for details.
• Authorization infrastructure. See
  Functional Specification for UCCAP Attribute Server and Attribute Query Protocol - a draft spec for review - and
  The Limited Production System: Authentication and Authorization
• Melweb
• Benweb

	signed, encrypted email
	signed web pages
	signed java applets
	wide distribution of certs
	legacy apps (all non-web apps?)
	portability?
	the workstation problem
	external services (Britannica)
	key archival/recovery/escrow
	workflow
	non-repudiation
	privacy, anonymous transactions, ...
	attribute certs
	role-based authentication
	distributed authorization (meta-directories, etc)
	fine-grained authorization (by course enrollment)
	commerce, money xfer (charge by the drink), ...

• Certificate payload will be MINIMAL. Not much about the individual beyond his NetID (=AuthHandle?). Not if it's a student, no addr, etc. Recommended Payload.
• UCCAP/LPS certs are not intended for use outside UC initially. They will be targeted for certain applications within UC and may not initially even be suitable for other UC applications. Policy and procedures for really strong certs are for another phase.

• cert portability
• CRL handling
• Directory Services/UDir
  • definition of Directory Services
  • relationship between UCOP/UDir and campus directories (central UDir distributed to locals or local Dirs consolidated to central? Who does the updates where...)
  • access tools? - LDAP??
• Certificate Policy and and Certificate Practice Statement (CPS)
• Legal ramifications - there are liability issues with PKI.
• export restrictions - how do they affect us?
• key-escrow (and the FOI - subpoena (or cart off) your key-escrow machine)
• Authorization. Authorization is ultimately the responsibility of the service provider. However, this hierarchy may be useful:
  • local server-supplied data
  • data supplied by the certificate issuer (ptr in the cert?)
  • campus-supplied data (well-known place or in UDir?)
  • UDir (DDB) (well-known place???)
  • doesn't care - just seeing a valid cert is good enuf
• Costs, long-term financial model - needs to be developed.
  $one-million/year @ UMinn? (rumor 9.1M)
  $59/seat (Entrust)
  $100/seat (Gartner)
  Maybe those aren't accurate, but we could be talking about real money...
• Performance, robustness

Miscellaneous Resources

Send your questions, comments, and suggestions to IR&C
Last updated November 4, 1999