439
edits
PSM:CertPrompt: Difference between revisions
Jump to navigation
Jump to search
→Issues with these scenarios
| Line 90: | Line 90: | ||
== Issues with these scenarios == | == Issues with these scenarios == | ||
IE's client authentication has the advantage of being a simple programming model (Find all the certificates, present them to the user, remember the user's selection forever). This model, however breaks down in the following cases: | |||
1) If there are no certificates available, users are confused by | |||
and empty dialog box asking them to select a certificate. | |||
2) If multiple certificates are available on the system, IE does | |||
nothing to help the user understand which certificate should be | |||
used to authenticate. | |||
3) Because of the current poor client/server interaction, the | |||
choice of the wrong certificate often gives the user no input | |||
as to why the connection failed. | |||
4) The model does not work well when the certificate can appear or | |||
disappear from the system (such as the smart card case). | |||
The model does work well in the following cases: | |||
1) The user has a single, fixed certificate. | |||
2) The user has multiple certificates which represent different roles, | |||
and the user is sophisticated enough to identify the proper certificate. | |||
3) The case where the server does not send a list of CA Certificates, or | |||
the list of CA certificates is not complete, and the user is sophisticated | |||
enough to select the proper certificate. | |||
PSM's 'always select' is targetted to the less sophisticated user. It breaks down in the following cases: | |||
1) Switching from no certificate to having a certificate | |||
(smartCard insertion) if the server does not invalidate the | |||
session id (server performance issue). | |||
2) The user has multiple certificates which represent different roles. | |||
3) The server does not send a list of CA Certificates, or the list | |||
of CA certificates is not complete. | |||
4) The user needs to do online renewal of an expired certificate. | |||
It works extremely well when: | |||
1) There is only one certificate. | |||
2) SmartCards are used, particularly when card insertion and removal | |||
detection is turned on, and the server invalidates the session id | |||
when no certificate is available. | |||
3) There are lots of certificates to choose from, but no role differentiated | |||
certificates. | |||
PSM's 'ask always' is targetted to the more sophisticated user. It breaks in the following cases: | |||
1) The user has a valid certificate, but the server always does full | |||
hand shakes (always invalidates the session id). | |||
2) Switching from no certificate to having a certificate | |||
(smartCard insertion) if the server does not invalidate the | |||
session id (server performance issue). | |||
3) The server does not send a list of CA Certificates, or the list | |||
of CA certificates is not complete. | |||
PSM Recommendations: | |||
1) Add a javascript function to clear the current ssl session id which | |||
can be called on smartCard insertion. This will elliminate the need | |||
for servers to invalidate the session id for firefox clients. | |||
2) Include on all the user's certificates in the 'ask always' list, with | |||
those that match the CA list at the top and clearly marked as matching, | |||
and those that do not match at the bottom. (currently we already do | |||
this for expired versus unexpired). | |||
3) Work on the server UI for fortitude to allow easy configuration of | |||
client authentication, so that client authentication errors are | |||
reported back to the client in a friendly manner. | |||
'''TODO: still need to figure out how best to handle the 'select always' user who needs to do certificate renewal.''' | |||
'''TODO: do we need to handle the 'select always' user in the case where the list of CA certificates do not match (this inherently requires a sophisticated user?).''' | |||