logging in or signing up robots banff Xavier Download Post to : URL : Related Presentations : Share Add to Flag Embed Email Send to Blogs and Networks Add to Channel Uploaded from authorPOINTLite Insert YouTube videos in PowerPont slides with aS Desktop Copy embed code: (To copy code, click on the text box) Embed: URL: Thumbnail: WordPress Embed Customize Embed The presentation is successfully added In Your Favorites. Views: 114 Category: Entertainment License: All Rights Reserved Like it (1) Dislike it (0) Added: January 02, 2008 This Presentation is Public Favorites: 1 Presentation Description No description available. Comments Posting comment... By: reosh (17 month(s) ago) very good Saving..... Post Reply Close Saving..... Edit Comment Close Premium member Presentation Transcript On Robots: On Robots J Jensen STFC Rutherford Appleton Lab Banff, 16-18 July 2007What is a Robot: 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: 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: I, Robot UK version: …/CN=Joe User/CN=Robot:GridClient Dutch version …/O=robots/…/CN=Robot: function - person Czech version? …? Your version?Robot Names: 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: 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 sufficientRobot toolkit for your CP/CPS: 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: 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 learnIssues: 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: 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: 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 RASecurity Issues: 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 keysSecurity Issues: 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: 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 nameOpen Questions: 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 You do not have the permission to view this presentation. In order to view it, please contact the author of the presentation.
robots banff Xavier Download Post to : URL : Related Presentations : Share Add to Flag Embed Email Send to Blogs and Networks Add to Channel Uploaded from authorPOINTLite Insert YouTube videos in PowerPont slides with aS Desktop Copy embed code: (To copy code, click on the text box) Embed: URL: Thumbnail: WordPress Embed Customize Embed The presentation is successfully added In Your Favorites. Views: 114 Category: Entertainment License: All Rights Reserved Like it (1) Dislike it (0) Added: January 02, 2008 This Presentation is Public Favorites: 1 Presentation Description No description available. Comments Posting comment... By: reosh (17 month(s) ago) very good Saving..... Post Reply Close Saving..... Edit Comment Close Premium member Presentation Transcript On Robots: On Robots J Jensen STFC Rutherford Appleton Lab Banff, 16-18 July 2007What is a Robot: 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: 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: I, Robot UK version: …/CN=Joe User/CN=Robot:GridClient Dutch version …/O=robots/…/CN=Robot: function - person Czech version? …? Your version?Robot Names: 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: 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 sufficientRobot toolkit for your CP/CPS: 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: 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 learnIssues: 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: 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: 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 RASecurity Issues: 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 keysSecurity Issues: 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: 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 nameOpen Questions: 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