<html> <head> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> </head> <body text="#000000" bgcolor="#FFFFFF"> <meta http-equiv="CONTENT-TYPE" content="text/html; charset=ISO-8859-1"> <title></title> <meta name="GENERATOR" content="LibreOffice 3.3 (Unix)"> <style type="text/css">  </style> Each IPA user will have the ability to request a cryptographic certificate. The primary usage for user certificates is for authentication in cases where Kerberos is not an option: Across firewalls and cases where cross domain trust has not been established. There are a range of options for implementing user certificates. The variables are the number of certificates per user, the work-flow for approving certificates, and tracking the approval agent for a certificate signing. The simplest use case is a user can have only a single certificate, and it gets approved automatically. This is the way host certificates currently work. The justification for automated approval is that the user has already authenticated themselves via Kerberos in order to request the ticket in the first place. There is an argument for allow a user to have multiple certificates. The user might have multiple devices, such as both a laptop and a cellphone, that should be independently authenticated. Allowing multiple certificates means that the user is not responsible for transporting private keys between the two devices, and thus they are less likely to accidentally expose it. It also means that revoking a certificate for a lost cell phone will not cut off all remote access for a user. Some organizations might decide that a certificate needs to require a higher guarantee of the users identity than just the Kerberos ticket. If certificate signing is not automated, then IPA is going to need both a queue to track certificate requests and a mechanism to notify the approval authority upon request submission. In order for a user to approve a CSR request, that user would need an appropriate ACI. This would be managed by IPA Roles. Approval of a certificate should then be an audited process, which could be done by customizing the User certificate profile to record the approving user. Heavy use of user certificates would provide a much larger load on the OCSP service proxied through the IPA server. This load would need to be taken into account during deployment planning. </body> </html>