Robots Jens Jensen, STFC RAL GridNet2/ UK e-Science CA /NGS/GridPP/

Contents What is a Robot Why robots (use cases) How Robots (how its done) Issues How Robots (Requirements)

What is a Robot A long-lived client certificate –Whose private key is unprotected –i.e. not protected with a passphrase Identity –Not tied to a network identity –Tied to a specific user (owner)

Use Cases Automated monitoring services Automated data transfer services Mail decipherment …

Robot Naming UK version: …/CN=Joe User/CN=Robot:GridClient Dutch version …/O=robots/…/CN=Robot: function - person Italian version /CN=Robot: function - person Your version?

Robot Names Mr Robot GridClient does not have : : is in printableString Simple algo to derive owners DN –But not the same for the two CAs Allow disambiguation –/CN=User Name/CN=Robot:Type (314) –No semantics associated to disamb.?

Robot Private Keys Held on key token Certificate not tied to a network entity Thus private key tied to physical host If the key is stolen, youll know it If host is compromised: –They can access the private key, signing stuff –But not steal it –Cannot be cloned either (except between virtual hosts?)

Robot toolkit for your CP/CPS Describe what a robot is Describe naming of robots –Including relation to owners 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

How to recognise a robot …from quite a long way away. Check the DN… –Does it have an addl CN with Robot: Check the policyIdentifier –Does it have any Robot 1SCP OID? –State of middleware doing this?

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

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 users robots) –Bad for transfer of ownership

Issues 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

Proposed Requirements Robots MUST have a 1SCP OID –Plus of course that of their CP/CPS Robots MUST NOT have server exts –Because they are not – not tied to DNS name –Does not make sense Private key held on secure token

Proposed Requirements Robot certificates MUST NOT be 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 –No further requirements on naming atm –Make recommendations ( RECOMMENDED )

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? Are robots too tied to their owners name? –Introduce robots owned by projects