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

[John Bradley <jbradley@mac.com>]

<inline>
On 7-Jan-09, at 1:18 PM, Michael McIntosh wrote:

> 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.
>
Agreed that is why we have the two options though they are at the  
discretion of the card issuer not the user.
>
> 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.
>
>
True we just need to make certain that issuers understand that.
> 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.
>
Agreed I think people are a bit clearer on this point.  However as you  
point out if the IdP is doing something stupid generating the PPID  
then the RP would be none the wiser even if it is doing the correct  
thing and checking PPID+Issuer Key.
>
>
> 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.
>
>
However the spec allows the IdP to do exactly that "The IP/STS MAY use  
this value as-is or as an input seed to a custom function to derive a  
value for the PPID claim"

We may want to have some words regarding the use of the value as is  
has potential security issues.

My only concern around Mike J's proposed change is that it now  
potentially allows the IP/STS to use the value as-is as opposed to  
calculating it itself for auditing mode cards.

Yes a IP/STS would have to be stupid to do that but they are out  
there,  we should have a word of warning why it is a bad idea.


> > 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.
>
>
Yes I think Parity is doing that with card press now that you mention  
it.
> > 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.
>
=jbradley

smime.p7s