1 / 15

Robot Names and Security Issues in Certificate Management

This presentation explores the intricacies of robot certificate management, discussing topics such as defining robots, naming conventions, security concerns, and authorization protocols. The session delves into the challenges and considerations when issuing certificates for robots, highlighting the importance of safeguarding private keys and ensuring proper authorization processes.

hachi
Télécharger la présentation

Robot Names and Security Issues in Certificate Management

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. On Robots J Jensen STFC Rutherford Appleton Lab Banff, 16-18 July 2007

  2. 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)

  3. 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.

  4. I, Robot UK version: …/CN=Joe User/CN=Robot:GridClient Dutch version …/O=robots/…/CN=Robot: function - person Czech version? …? Your version?

  5. 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.?

  6. 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

  7. 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)

  8. 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

  9. 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)

  10. 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?

  11. 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

  12. 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

  13. 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?

  14. 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

  15. 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

More Related