150 likes | 585 Views
On Robots J Jensen STFC Rutherford Appleton Lab Banff, 16-18 July 2007 What is a Robot A long-lived user certificate Whose private key is “unprotected” MUST be protected with a passphrase Passphrase MAY be stored in memory Identity Not tied to a network identity
E N D
On Robots J Jensen STFC Rutherford Appleton Lab Banff, 16-18 July 2007
What is a Robot • A long-lived user certificate • Whose private key is “unprotected” • MUST be protected with a passphrase • Passphrase MAY be stored in memory • Identity • Not tied to a network identity • Tied to a specific user (owner)
You, Robot • Robots MUST have a 1SCP OID • Plus of course that of their CP/CPS • Robots MUST NOT have server exts • Because they are not • Servers need DNS name in s.a.n.
I, Robot UK version: …/CN=Joe User/CN=Robot:GridClient Dutch version …/O=robots/…/CN=Robot: function - person Czech version? …? Your version?
Robot Names • “Mr Robot GridClient” does not have ‘:’ • ‘:’ is in printableString • Simple algo to derive owner’s DN • But not the same for the two CAs • Allow disambiguation • /CN=User Name/CN=Robot:Type (314) • No semantics associated to disamb.?
Issues • Robots are named after what they are, not what they do. • E.g. “GridClient”, not “Monitoring” • Get consistent naming for all robots? • Should different robots have different OIDs (in addition to robot 1SCP) • Probably not – profile should be sufficient
Robot toolkit for your CP/CPS • Describe what a robot is • Describe naming of robots • Including relation to owner’s name, if any • Condition of issuance (who can request) • Security of private key (cf token talk)
Robot toolkit for CP/CPS • Perhaps make it a part of a consistent CP/CPS programme (CCPCPSP)? • Mix and match, • Plug and play, • Live and learn
Issues • Must robots always name their owner? • Good for log files and the W&F • Good for AUC by DN (W&F) • Good for automated chaining (user leaves disable user’s robots) (but no stds) • Bad for transfer of ownership • Bad for “shared” robots (with 1 responsible) (project owned)
Issues • Which types • Use cases (for owners, projects, and the CA) • How to describe different types • Morally equivalent to services • Define std ones • Harmonise std ones across PMA? • Each CA MUST describe non-std ones • But not in CP/CPS?
Issues • How RA verifies key generated by token • General token support, not just for robot • Different modus operandi for users • More work for the helpdesk, more work for the RA
Security Issues • Robot certificates shared? • Single person responsible for use of robot • CA decides what it is, owner what it does • Each Robot has a unique DN • No two Robots share keys
Security Issues • MUST be authorised independently • of the user’s authorisation • Private key is “unprotected” at time of use • Permit non-protected tokens (LoA…) • Should owner use existing cert to apply for robot cert?
Open Questions • Can anyone apply for a robot? • If not, how should it depend on the type? • Distinguish simple from powerful robots • Other than by extns • How to enforce what it does (cf Globus services) • Bit like object signing extensions • How does CA assert this? • Robots too tied to their owner’s name
Open Questions • How to get consistency across CAs (cf 1SCP) • Is this necessary • Makes life easier for reviewers • At least need a robot profile…, no? • Consistency (probably) impossible already