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
On Feb 21, 2010, at 3:42 PM, Paul Battersby wrote:
Hi Paul,
I’ve done a bit more investigation into this from our side using the following scenarios from our Cloud selector:
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.
Also, once the card is found and the selector contacts the Azigo STS web service I get an error:
HTTP/1.1 500 Internal Server Error
Date: Sun, 21 Feb 2010 20:20:35 GMT
Server: Apache
Accept: application/soap+xml, text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
SOAPAction: ""
Content-Length: 297
Connection: close
Content-Type: application/soap+xml;charset=utf-8
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"><env:Header/><env:Body><env:Fault><env:Code><env:Value>env:Receiver</env:Value></env:Code><env:Reason><env:Text xml:lang="en">Incorrect result size: expected 1, actual 0</env:Text></env:Reason></env:Fault></env:Body></env:Envelope>
Do you have any clues as to this difference in behavior and the error code that I’m receiving?
Thanks in advance,
Paul Battersby.
From: Paul Trevithick [mailto:Paul@azigo.com]
Sent: 19 February 2010 3:26 PM
To: Pamela Dingle
Cc: Paul Battersby; Susan Morrow
Subject: Re: PPID calculation Hi Pam,
We're looking into these incompatibilities...
I know I tried to export personal backed managed cards from azigo to cardspace classic and got errors.
Can we get a copy of that/those cards by any chance?
On Feb 18, 2010, at 4:32 AM, Susan Morrow wrote:
Hello Paul,
We met last year at the OpenID summit.
We have been testing with various cards in readiness for the test run this Friday for RSA and have come across a few issues with the Azigo cards backed by a personal card. I asked Pamela if she had any ideas about this and she said she also has had similar problems (see thread below).
We were wondering if this was related to the way you calculate your PPID – do you use the IMI V1.5 to do this?
Be useful if you could let us know, so we can get to the root of the problem and try to get interoperability with all cards.
All the best
Susan
Registered Office: Avoco Secure, 8 Clifford Street, London W1S 2LQ
Company number : 04778206 - Registered in England and Wales.
secure2trust has been awarded SC Magazine Best Buy and 5 stars in 2006 and 2008
Avoco Secure is a member of the Microsoft Secure IT Alliance which is defining the industry security solutions.
The Butler Group believes that secure2trust can provide organisations with a level of protection for content that cannot be provided through other types of applications.
This email including any attachments is confidential and may be legally privileged. This email is intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient, be advised that you have received this email in error, please advise the sender IMMEDIATELY by return email and then DELETE it from your system. The unauthorised use, distribution, dissemination, copying or alteration of this email is strictly FORBIDDEN.
2.
Re: [imi-interop-tech] Re: PPID calculation
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
This thread already has a best answer. Would you like to mark this message as the new best answer?