| On the OSIS call today John Bradley pointed out another bug in Azigo:
- Azigo 2.0.0.40 and CardSpace .Net 3.5 SP2 generate different (and thus incompatible) PPID values on p-cards for the PayPal site (site with an EV cert)
--Paul On Feb 22, 2010, at 2:51 PM, Paul Trevithick wrote: Paul and Susan,
Here's is where we are on one of the issues that you both (and Pam) have run in to... I used this as an opportunity to summarize what I understand. I'm hoping anyone on this list can chime in to correct anything I've gotten wrong.
Specifications
There are three specifications of how to compute the PPID. I have invented the term "IMI 1.0a" - ISIP 1.0
- IMI 1.0 (also known as ISIP 1.5)
- IMI 1.0a is IMI 1.0 with the change described in [2]): (see Changes Made in ISIP V1.5 on page 72). It says: "To provide a migration path from non-EV to EV certs, the RP PPID Seed for a non-EV cert containing the same OLSC values is the same as for an EV cert, resulting in the same PPID"
CardSpace Versions
- .Net 3.0 version: implements ISIP 1.0 (according to [1])
- .Net 3.5 version: implements ISIP 1.5 (according to [1])
- .Net 3.5 SP1 version: (i) implements IMI 1.0a for token of p-card (ii) implements ISIP 1.0, IMI 1.0 and IMI 1.0a (all three) to find a p-card that matches the PPID credentials of a "backed" m-card.
- .Net 3.5 SP2 version: same as .Net 3.5 SP 1?
- CardSpace 2.0 beta version: same as .Net 3.5 SP 1?
Azigo Versions
- 2.0.0.35 --> 2.0.0.40 versions: implements IMI 1.0
Avoco Versions
- It appears to use some different PPID logic than CardSpace WRT to finding a matching p-card against the PPID of a backed m-card.
Incompatibilities (bugs):
- Pam reported: You can't export a p-card backed m-card from Azigo 2.0.0.35 and import into .Net 3.5 SP1 version of CardSpace.
- PaulB reported: 1) An Azigo Managed card backed by a CardSpace Personal card using a crds imported from CardSpace. 2) An Azigo Managed card backed by an Azigo Personal card using a crds imported from Azigo Desktop selector. In the first case the PPID matches (i.e. the PPID calculated by the selector matches the PPID stored in the managed card). The algorithm uses a Relying Party Id generated from |O=*.azigo.net|L=|S=|C=|. The second scenario fails. However, if I force the code to use a Relying Party Id generated from the public key of the certificate then the PPID matches. This is rather strange as the certificates in the Managed cards from both scenarios are exactly the same and the public key should only be used if the certificate is not valid or the Organizational units are empty.
The above bullets are caused by the same set of inter-related issues. The root cause is an inability to validate the certificate of cardpres.azigo.net and as a result Azigo computes the wrong PPID for this site. We thought that we could fix this by including then entire certificate chain in the .crd. We did this today, but there are other related issues and we need another 2 days to deploy a new version of our hosted i-card service (service.azigo.com)
--Paul
|