Fwd: [ICF.WG.OASIS] Re: Issues to consider for discussion with IMI-TC PPID computation issue & interop

[John Bradley]

Pam,  the simple solution is to join the google group:)

You are an ICF member?

=jbradley

Begin forwarded message:

From: "Pam Dingle" <pdi...@nulli.com>

Date: January 9, 2009 7:45:10 PM GMT-03:00

To: "John Bradley" <ve7...@ve7jtb.com>,  "Nennker, Axel" <Axel.N...@t-systems.com>

Cc: "Dale Olds" <do...@novell.com>

Subject: Re: [ICF.WG.OASIS] Re: Issues to consider for discussion with IMI-TC PPID computation issue & interop

Darn whitespace.

Axel, if you could issue me a managed card known to break my RP,  I can use that token as an example to create a new IdP test at http://test.pamelaproject.com (an IdP site that munges tokens on demand).   If you can give me an example of an RP that correctly processes a signing key with whitespace in it, I'd have everything necessary to create and test an OSIS test.

This should definitely be explicitly mentioned in the spec, since interoperability is obviously affected. 

I haven't bothered to copy the list on this email since I'm not a member and therefore expect my email to bounce - feel free to forward this on if you think others would care.  I've logged a ticket for PamelaWare here:  "http://code.pamelaproject.com/ticket/3796".

Thanks,

Pamela

On Fri, Jan 9, 2009 at 1:09 PM, John Bradley <ve7...@ve7jtb.com> wrote:

It is probably fair to say that we are seeing incorrect behavior however I hesitate to put the fault entirely on the RPs.

If the spec is ambiguous then we should probably have it clarified and perhaps add the issue to the interop tests.

It seems that there are two ways to correct this one is to adopt the behavior of Cardspace to accommodate RP's who are not dealing with line breaks in the base-64 encoded signing key,  or make the spec clear that the RP's should base-64 decode the signing key before storing it.

Personally I think the latter is the correct thing to do that is why it is base-64 encoded after all:)

That then raises the question "Is the spec itself in need of clarification, or is this just a case of RP's taking a shortcut in violation of the spec.

Pam/Dale do you find the ISIP 1.5 spec or the IMI 1.0 spec unclear on this?

With that feedback we can decide if we should recommend a wording change to the editors (Mikes)

Anyone with an opinion on the other issues.

I have added the link to the current IMI draft on the WG wiki for peoples reference.    

If we can start refereeing to that document regarding proposed changes it will make it easier for the editors.

=jbradley

On 9-Jan-09, at 4:28 PM, Axel Nennker wrote:

I included Pamela und Dale because their RPs handle the signing-key-
base64 "incorrectly".

I think RPs should base64-decode the base64-encoded-signing-key before
hashing and probably base64-encoding the hash to store it in the RP's
userDB.

-Axel

On 9 Jan., 18:19, John Bradley <ve7...@ve7jtb.com> wrote:

We need to get this group spun up to start providing feedback to the  

IMI-TC as the new spec is currently being edited by the two Mikes.

Other issues or corrections that people want raised or comments to the  

below should be posted to this list.

Regards

John Bradley

1) Axel has raised one issue on the OSIS list:

I am already not happy with the PPID test for selectors.

e.g.:http://osis.idcommons.net/wiki/I5:FeatureTest-Selector_PPID_Construct...

"Tests that a selector properly creates the PPID for an EV SSL RP"

What does "properly" mean in this case? ISIP 1.5 says how the PPID

SHOULD be computed.

The PPID MUST be unlinkable. Everything else is a SHOULD.

"4.3.4. Client Pseudonym

A private personal identifier (PPID), defined in Section 8.5.14,

identifies a Subject to a Relying Party in a way such that a Subject"s

PPID at one Relying Party cannot be correlated with the Subject"s PPID

at another Relying Party. If an Identity Provider offers the PPID

claim type then it MUST generate values for the claim that have this

prescribed privacy characteristic using data present in the RST

request."

The "privacy property" (unlinkablity) is the MUST not the suggested

algorithm.

Other potential issues that have come up from Higgins work.

2. According to 8.6.1 of [1], "stateOrProvinceName" attribute name of  

subject of certificate is "S", but in real certificates it is "ST".  

So, PPID was incorrect for those RPs, whose certificate subject  

contains "ST" attribute (I missed "ST" because expected "S").

3. Login to some RPs (likehttps://www.equalsdrummond.name,https://cards.bandit-project.org/BanditIdP/,https://pamelaproject.com...

  <https://pamelaproject.com/pwdrupal/>  ) is not compatible between  

higgins and cardspace. In other words, if we create an account on  

those RPs using cardspace, we could not login with the same card from  

higgins (and vice versa).

Actually, those RPs use token signing key instead of PPID to  

authenticate users, but they are doing it incorrectly. Signing key is  

present in token as base64-encoded string. RPs code takes this string  

and makes a hash from it. It is a wrong behaviour, because base64-

encoded string can be wrapped into a few lines without loosing  

information. So, though both cardspace and higgins sends the same  

signing key, RPs calculate different hashes, because cardspace sends  

it as single line but higgins sends it as wrapped line (appache xml  

security library wraps it when signing a token). I roughly fixed it in  

sts.xmlsecurity.apache project. But, it looks it should be fixed in  

code of RP, not in higgins STS.

[1] Identity Selector Interoperability Profile V1.5

[2]  An Implementer's Guide to the Identity Selector Interoperability  

Profile V1.5

 smime.p7s

3KAnzeigenHerunterladen

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "ICF-WG-OASIS" group.
To post to this group, send email to icf-wg...@googlegroups.com
To unsubscribe from this group, send email to icf-wg-oasis...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/icf-wg-oasis?hl=en
-~----------~----~----~----~------~----~------~--~---