The good news is that the current PPID algorithm doesn’t use the
cert chain – just specific fields from the leaf cert that are expected to be
invariant across cert renewals and even change of cert provider.
Cheers,
--
Mike
From: Anthony Nadalin
[mailto:drsecure@us.ibm.com]
Sent: Thursday, January 08, 2009 7:08 AM
To: John Bradley
Cc: imi@lists.oasis-open.org; Mike Jones
Subject: Re: [imi] Clarifications to the spec to discuss for our call on
Thursday
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