Comments on: Managed Card Portability

By: ignisvulpis

ignisvulpis — Thu, 24 Apr 2008 09:41:36 +0000

Here is what the XMLDAP STS does: http://code.google.com/p/openinfocard/source/browse/trunk/src/org/xmldap/sts/servlet/Utils.java#226
http://tinyurl.com/5fn7eg
In English:
If the id selector presented a PPID in the RST then just use that.
If the id selector provided the RP certificate then take the certs’ encoded bytes and concatenet with the STS PPID and then compute a SHA1 hash of the result. This hash is the returned ppid in the token.
Else if I don’t know the RP cert but I have a value for “restrictedTo” then concatenate this with the STS PPID, hash the concatenated bytes as before and return the result.
Else if neither of the above is known then just return the STS ppid associated with the card which makes this ppic linkable.

As you can see in the comments in the code using the whole encoded bytes of the cert was never considered a good idea. But alternatives are not really easy to find as each variant has its own drawbacks. Comments and suggestions are very wellcome.

By: Pamela

Pamela — Wed, 23 Apr 2008 16:20:57 +0000

I’m glad you pointed to that entry – I hadn’t read it yet and it brings up yet again more interesting points, for example I didn’t know that the FQDN was not used in creating the ppid!

Personally, I would think that an STS would have to think long and hard before implementing something that changes the outwards behavior of the black-box system that is supposed to be a managed card.

I’ll have to do some impromtu testing on whether signing key changes for managed cards when imported between browsers – I don’t know if I’ve ever done such a thing in my PamelaWare testing…

By: BarryD

BarryD — Wed, 23 Apr 2008 05:58:52 +0000

Remember it’s up to the STS to generate a PPID, assuming they want to support it.

Right now we’re all lazy *grin* We simply reflect back the suggested one that comes down as part of the ClientPseudonym in the RST. This is generally a bad idea, not just for the reason you give, but because that PPID is not immutable, it may change with the RP SSL certificate (I’ve moaned about this before; http://idunno.org/archive/2008/02/02/certificates-information-cards-ppids-and-misconceptions.aspx )

Having said that the PPID itself should be constant with the same card, imported into different selectors. It’s the signing key that will vary, and as you point out this needs to be combined with the PPID to make something unique. Thinking about it, it’s worse than you think. If the key is per selector then even exporting a self issued card and importing on a new machine means a new signing cert, and authentication fails if an RP is following best practice.

Now yes, in a non-auditing STS there’s no other way to provide a PPID (and I am not convinced you actually need to offer on), but once you slip into auditing mode, where you know the identity of the RP there’s a whole world of possibilities; including say “Sod off” to the ClientPseudonym and doing it yourself; which, to my mind, is the right thing to do. Well, it would be, if there was an easy way to work out if the RP has an EV certificate rather than have a master table of EV OIDs.