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

[Anthony Nadalin <drsecure@us.ibm.com>]

The certificate chain can produce different results, we have already seen this

Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122

John Bradley ---01/08/2009 08:25:52 AM---Better, thanks Mike.

From:	John Bradley <jbradley@mac.com>
To:	Mike Jones <Michael.Jones@microsoft.com>
Cc:	"imi@lists.oasis-open.org" <imi@lists.oasis-open.org>
Date:	01/08/2009 08:25 AM
Subject:	Re: [imi] Clarifications to the spec to discuss for our call on Thursday

---

Better, thanks Mike.

For auditing mode cards do we want to say that the IP/STS SHOULD use the certificate chain to produce the PPID with a cryptographically non-invertible function, such as the one used to calculate the PPID for p-cards.

If we are going to have the spec say that the selector should send the PPID for auditing mode cards,  I don't want to infer that using that even with a hash function is better than calculating it from the site cert chain.

=jbradley
On 7-Jan-09, at 11:52 PM, Mike Jones wrote:

OK, based on a private discussion on this topic with John, I’m going to suggest that we change the language “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” to “The IP/STS SHOULD combine this PPID seed value with constant information known to the IP/STS and pass the combination through a cryptographically non-invertible function, such as a cryptographic hash function, to generate the PPID claim value sent in the signed token”.

-- Mike

From: John Bradley [mailto:jbradley@mac.com]
Sent: Wednesday, January 07, 2009 1:02 PM
To: imi@lists.oasis-open.org
Subject: Re: [imi] Clarifications to the spec to discuss for our call on Thursday

<snip>
On 7-Jan-09, at 5:17 PM, Michael McIntosh wrote:



John Bradley <jbradley@mac.com> wrote on 01/07/2009 02:21:00 PM:
>
> <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.

Not completely.
The IdP (AKA Card Issuer) gets to specify whether the RP identity is required, not required, or optional - and that information is in the card and/or IdP metadata (I forget which).
The RP gets to specify whether or not a specific IdP is required, or whether any is acceptable.
The user gets to select which card (and therefore which IdP) will be used.

If a user does not want to use a card that requires disclosure of RP identity to the IdP, it can choose another card.
If the only cards the user has that match the RP policy are cards that require RP disclosure, the user can go elsewhere.
As far as I know there is nothing in the selector that tells the user that it is going to disclose the identity of the RP to the IdP.

So I agree that in principal the user is free to select any card that matches the required claims but if they have two cards one auditing and one not they have no easy way to distinguish between them.

I have to go back and look at how optional auditing mode works that is a new one to me.

As near as I can see with current selectors the power is in the hands of the IdP, unless I am missing something.

=jbradley