On Robots J Jensen STFC Rutherford Appleton Lab Banff, 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