Issues to consider for discussion with IMI-TC PPID computation issue & interop
John Bradley
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_Construction_for_RP_using_EV_SSL#Selector_PPID_Construction_for_RP_using_EV_SSL
"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 (like https://www.equalsdrummond.name, https://cards.bandit-project.org/BanditIdP/,https://pamelaproject.com/pwdrupal/ <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
Axel Nennker
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.
> 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").
>
> 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
>
> 3KAnzeigenHerunterladen
Paul Trevithick
On 1/9/09 2:46 PM, "John Bradley" <jbra...@mac.com> wrote:
> Yes the page needs updating.
>
> For the moment until the ICF joins OASIS, the process will need to
> involve myself or one of the other IMI-TC members taking the feedback
> to the IMI-TC.
>
> Issues can be posted and discussed on the list. If people feel a need
> for calls we can set one up.
> However most of us have more than enough calls and the list provides
> for more accurate records of discussions.
>
> I prefer starting this as a email only group to track IPR issues if
> they arise.
>
> We will also need to get an IPR agreement for the members of the WG to
> agree to once we move beyond making what at this point could be
> considered Errata for the ISIP 1.5 spec to be incorporated in the
> Identity Metasystem Interoperability Version 1.0
> spec.
>
> I don't see this as a replacement for people joining the IMI-TC
> directly. Unfortunately for various reasons some people are finding
> it difficult or impossible to join for a number of reasons.
>
> =jbradley
>
> On 9-Jan-09, at 4:11 PM, Paul Trevithick wrote:
>
>> John,
>>
>> I take it the process is that folks post to this list, a discussion
>> ensues (or doesn¹t), a decision is made as to whether to document
>> the issue, and then you ?? take the resulting document and submit it
>> as ³ICF input² to the appropriate OASIS TC. Is that about right?
>>
>> Seems like this page [1], is in need of updating. Perhaps it could
>> include some bullets about the WG¹s process (as above).
>>
>> --Paul
>>
>> On 1/9/09 12:19 PM, "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_Construction_fo
>>>> r_RP_using_EV_SSL#Selector_PPID_Construction_for_RP_using_EV_SSL
>>>> "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 (like https://www.equalsdrummond.name,
>>>>> https://cards.bandit-project.org/BanditIdP/,https://pamelaproject.com/pwdr
>>>>> upal/
>>>>> <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
John Bradley
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
John Bradley
Yes the page needs updating.
For the moment until the ICF joins OASIS, the process will need to involve myself or one of the other IMI-TC members taking the feedback to the IMI-TC.
Issues can be posted and discussed on the list. If people feel a need for calls we can set one up.
However most of us have more than enough calls and the list provides for more accurate records of discussions.
I prefer starting this as a email only group to track IPR issues if they arise.
We will also need to get an IPR agreement for the members of the WG to agree to once we move beyond making what at this point could be considered Errata for the ISIP 1.5 spec to be incorporated in the Identity Metasystem Interoperability Version 1.0
spec.
I don't see this as a replacement for people joining the IMI-TC directly. Unfortunately for various reasons some people are finding it difficult or impossible to join for a number of reasons.
=jbradley
On 9-Jan-09, at 4:11 PM, Paul Trevithick wrote:John,I take it the process is that folks post to this list, a discussion ensues (or doesn’t), a decision is made as to whether to document the issue, and then you ?? take the resulting document and submit it as “ICF input” to the appropriate OASIS TC. Is that about right?Seems like this page [1], is in need of updating. Perhaps it could include some bullets about the WG’s process (as above).--Paul
On 1/9/09 12:19 PM, "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.RegardsJohn Bradley1) Axel has raised one issue on the OSIS list:I am already not happy with the PPID test for selectors.e.g.:
"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 PPIDSHOULD be computed.The PPID MUST be unlinkable. Everything else is a SHOULD."4.3.4. Client PseudonymA private personal identifier (PPID), defined in Section 8.5.14,identifies a Subject to a Relying Party in a way such that a Subject"sPPID at one Relying Party cannot be correlated with the Subject"s PPIDat another Relying Party. If an Identity Provider offers the PPIDclaim type then it MUST generate values for the claim that have thisprescribed privacy characteristic using data present in the RSTrequest."The "privacy property" (unlinkablity) is the MUST not the suggestedalgorithm.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 (like https://www.equalsdrummond.name, https://cards.bandit-project.org/BanditIdP/,https://pamelaproject.com/pwdrupal/ <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.