Relying Parties often identify subjects using the Private Personal Identifier (PPID) claim and Signing Key values sent by an Information Card. Thus, it is important that the PPID and Signing Key values produced by a card be stable and long-lived.
Unfortunately, the PPIDs and Signing Keys generated by self-issued (a.k.a. personal) Information Cards using the algorithm originally shipped with Windows CardSpace (and documented in ISIP V1.0) for sites using regular certificates were not stable under several important conditions. Therefore, after considering industry feedback on the long-term problems that this continued instability would cause, and in consultation with other Identity Selector authors, a decision was made to change these algorithms in a way that will provide much better long-term stability of these important Subject identifiers for Relying Parties. The new algorithm is documented in the Identity Selector Interoperability Profile (ISIP) V1.5.
This change shipped with the version of Windows CardSpace in the .NET Framework 3.5 Service Pack 1. This service pack will be installed by Windows Update on systems with the .NET Framework 2.0, 3.0, and 3.5 in the coming months. I know that the Bandit and Higgins projects have implemented the new algorithm as well.
Unfortunately, this change means that the PPIDs and Signing Keys for self-issued cards used at existing Relying Parties that employ standard SSL certificates will change after this installation.
What Sites Need to Do
Sites need to ensure that they have tested mechanisms in place to enable their users to re-associate their Information Card with their account when the card’s PPID and Signing Key change. The good news is that these mechanisms are likely already in place in the form of “lost card” handling procedures.
When the card is used after the update, it will appear to be an unrecognized card. Just as sites’ lost card procedures can be used today to associate a new Information Card with their account, these same procedures can be used to re-associate the existing card with the account after these changes.
These lost card procedures will typically involve sending the user a message at the e-mail address of record for the account. This message contains a link that enables them to associate an Information Card with their account. This flow is nearly identical to the “lost password” flows often found on sites. Best practices for lost card handling are documented in the “Enabling Information Card Recovery” section of Patterns for Supporting Information Cards at Web Sites: Personal Cards for Sign up and Signing In.
Additional Steps Sites Could Take
In the short term, sites could also choose to add text to their Information Card login pages warning users that their existing cards will not be recognized as being associated with their accounts after the .NET update, and directing them to use the “lost card” feature of the site to remedy this situation.
EV and no-SSL Sites Not Affected
None of this affects sites using Extended Validation (EV) certificates or sites not using SSL certificates. These algorithms were already stable and have not changed. No action is required in these cases.
Background on the Problem
Because the original PPID and Signing Key algorithms used the entire certificate chain, these values could change under several circumstances:
- First, as sites renew their certificates, it is common for the certificate chain for the new cert to differ from the old one. This would change the PPID, breaking the user’s self-issued cards at those sites. And of course, the chain always changes if the site changes its certificate provider.
- Second, because the algorithm for converting the bytes of the chain certificates into characters was not fully specified by ISIP V1.0 for some OIDs, for some kinds of certificates, different Identity Selectors produced different results for the PPID claim, Signing Key, Client Pseudonym PPID, and IP Identifier values.
- Finally, in ISIP V1.0, the PPID for a site using a non-EV certificate is different than the PPID for a site that uses an EV certificate, even in the case where the non-EV leaf cert content meets the EV issuance criteria. This means that when a site upgraded to using an EV certificate, user’s cards would stop working at that site.
Overview of the Solution
To address these issues, the computation of the PPID and Signing Key for sites using regular certificates has been changed to no longer include information from the certificate chain, but only information from the leaf certificate. This will provide stability both when certificates are renewed and when a certificate is obtained from a new issuer.
Furthermore, the new algorithm generates the same PPID values for sites using EV and non-EV certificates with the same leaf certificate information, while generating different Signing Keys. This will help enable a smooth migration path for sites upgrading from non-EV to EV certificates because the PPID remaining the same can be used as evidence that the same card is being used before and after the certificate upgrade.
More about the specifics of the algorithm change can be found in Section 8.6.1 of ISIP V1.5 and additional guidance and commentary can be found in the corresponding section of the ISIP V1.5 Guide.
Posted under Documentation & Information Cards & Interoperability & Windows CardSpace