SlideServe
Télécharger Obtenir Pro
Menu
Accueil Pro
Préférences
ApparenceLight Aide et commentaires
© SlideServe · v2026

Robot Names and Security Issues in Certificate Management

hachi avatar
hachi
15 diapositives · 242 Views · Sep 17, 2014

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.

#robot names and security issues in certificate management #robot names and security issues in certificate management ppt #powerpoint #presentation
Robot Names and Security Issues in Certificate Management - slide 1
01 / 15Robot Names and Security Issues in Certificate Management
1 / 17

Télécharger la présentation

Robot Names and Security Issues in Certificate Management
Une image / un lien ci-dessous est fourni (tel quel) pour télécharger la présentation

Politique de téléchargement : le contenu du site vous est fourni TEL QUEL pour votre information et votre usage personnel ; il ne peut être vendu, concédé sous licence ni partagé sur d’autres sites sans l’accord de son auteur.Le contenu vous est fourni TEL QUEL, pour votre information et votre usage personnel uniquement. Téléchargez la présentation en cliquant sur ce lien. Lors du téléchargement, si vous ne parvenez pas à télécharger une présentation, l’éditeur a peut-être supprimé le fichier de son serveur.Pendant le téléchargement, si vous ne parvenez pas à obtenir une présentation, le fichier a peut-être été supprimé par l’éditeur.

F I N

Plus de contenu associé

Transcription de la présentation

  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