Re: [imi] Clarifications to the spec to discuss for our call on Thursday

[Michael McIntosh <mikemci@us.ibm.com>]

John Bradley <jbradley@mac.com> wrote on 01/07/2009 11:00:04 AM:

<snip>  
>
> However a IP/STS trusting a PPID coming from a selector has always
> made me a bit nervous.   I could as an example modify the Higgins
> selector to send arbitrary PPID values in a RST.  If the IP/STS say
> Verisign blindly includes it in its signed response the RP checking
> the PPID and sig as it would for a p-card could be spoofed if it was
> relying solely on those two values.
>
> Including a pre-calculated PPID may make some IP/STS lazy and not
> calculate it themselves when they clearly can.
>
> Minimally I think the PPID coming from the selector should be used
> as input to some other hash function to at-least make spoofing more difficult.
>
> I know the spec allows for using the PPID as input to a custom
> function,  but I have never seen an explanation of why that is a good idea.  
>
> I am OK with always including the PPID in the request if someplace
> we document the security issues around PPID in m-cards.

In order for the IdP to compute the PPID, it needs to know the RP ID.
A user may not want to tell the IdP the name of every site they visit.
If the User's client computes a partial ClientPsuedonym as input to the PPID computation,
a proper PPID can be computed by the IdP,
assuming it also includes some additional user specific "secret" into the computation,
without letting the IdP know the RP.

Any RP that blindly accepts a PPID and not a signed PPID+Issuer Key as the User's identifier is looking for trouble.
Any user can set up an Issuer to generate a token with any PPID.

Any IdP that blindly returns the ClientPsuedonym as the PPID is looking for trouble.
Any user with an account on that same IdP can send another user's ClientPsuedonym and get a token from the IdP.

> Mike Jones <Michael.Jones@microsoft.com>
>
> In practice, the IssuerId is only used for managed cards backed by
> self-issued cards. Therefore, I propose to change “The element
> content may be empty” to “The element content may be empty when the
> card is not a managed card backed by a self-issued card” and to change “The
> ic:IssuerId value SHOULD be the empty string for self-issued cards” to “The
> ic:IssuerId value SHOULD be the empty string for self-issued cards
> and MUST NOT be empty for managed cards backed by self-issued cards”.
>

I don't agree. There are some IdP endpoints hosting multiple logical Issuers (different signing keys) that need this value to determine the correct Issuer.

> 3. Clarifying that self-issued cards support the PPID claim even
> though not listed as an ic:SupportedClaimType element
>
> I have recently learned that even though all self-issued cards
> support the PPID claim, when self-issued cards are written to the
> Information Cards Transfer Format (a .crds file), the PPID claim is
> not listed as a SupportedClaimType in the card’s
> SupportedClaimTypeList. I propose that we document this anomaly in
> the specification so implementations behave consistently.

Why not just add the ClaimType for PPID? I agree with Tony that there might need to be multiple PPID algorithms supported and maybe the claim type would need to specify the algorithm(s) supported.