User:Martinlanghoff/Key Autonomy: Activation Server Requirements

Framework needs

• Install / upgrade / version mgmt (including DB schema versioning!)
• Must work in any domain, url, directory, etc.
• Must handle http and https use transparently.
• Config mgmt
• User management (inc "lost password", etc)
• Rights / roles / access control mgmt
• 'Noticeboard' on login
• "email all users"
• Logging of user actions
• Sane logging of errors, sane DB handling

Activation server

• MFG data import
  • Should it be only SN/UUID or the whole MFG data?
    • Deployments currently get SN/UUID - in Excel!
  • upload & queue for import split process
  • "status" of running import
  • report / log on completion
  • import is wrapped in SQL transaction: if it really goes wrong, it's rolled back
  • import identifier -- to optionally delete all imported data soon after import
  • retries?
  • updates?
• MFG data queries UI? (NTH)
• Management of which XO is in each school
  • XO SN-> School
  • XO SN-> Box SN -> School (NTH)
  • To explore: inventory needs beyond XO-to-School mapping

General

• Generate short lived "recovery activation keys" - universal / per school
• Generate and publish delegation keys for XSs
  • Handle offline XSs and online XSs separately
• Generate devkeys for technical team
• Receive devkey requests, and manage "delayed" workflow for generating them, with a chance for admins to deny the request.
• Allow marking an XO as 'STOLEN' - triggers active kill
• Serve the 'upgrade' URL in the OATs message if so configured
  • Maybe also serve the rsync service
• Protect the master keys

Cases to consider

• Workflow for "child + XO moving to a new school" (double-listed?)
• Workflow for "new XOs in a school"
• Workflow for "schooling is over, free up this XO"? Just "request your devkey" maybe?

Design notes

Now that we have delegations working well for activation keys and OATs messages, we can keep the signing machine offline, and design a workflow where we do a regular (weekly?) round of usb-disk traffic as follows:

• Read from the Activation Server
  • SN/UUID/School && each XS keys -- use to generate per-XS-delegations
  • SN/UUID of all XOs && the Activation Server keys -- use to generate OAT/Activation delegations for the Activation Server.
  • SN/UUID of devkey requests -- use to generate devkeys.
    • What happens w this cycle when we get a new XO in a School?
• Put the usb disk in the signing machine - create the needed files
• Return to the Activation Server
  • Delegations to XSs can be served via bare HTTP
  • Delegations to the AS's own keys are used
  • Devkeys to be served via HTTP

Note: we must make this work in cases where the Activation Server is only accessible via HTTP by the managers of the activation infra. Making both ends handle self-contained zipfiles (with sha1 manifests) would for example make it easier and more reliable. So include in the requirements:

• Web UI to manage requests to the signing server and responses.

...

Target OS

we'll want to package and test this...

• RHEL is so old we have to repackage/rebuild/retest dependencies
• On Fedora 11 we have all packages, but we tie clients to an upgrade treadmill
• Ubuntu LTS or Debian: repackage it all :-/