[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [imi] Clarifications to the spec to discuss for our call onThursday
--Apple-Mail-108--279724061
Content-Type: multipart/alternative;
boundary=Apple-Mail-107--279724132
--Apple-Mail-107--279724132
Content-Type: text/plain;
charset=WINDOWS-1252;
format=flowed;
delsp=yes
Content-Transfer-Encoding: quoted-printable
True, I was thinking of the 1.5 alg that the selector is using to =20
produce the "Client Pseudonym" now.
The Cert chain is needed for verification but only the client cert is =20=
used to produce the PPID.
=3Djbradley
On 8-Jan-09, at 12:08 PM, Anthony Nadalin wrote:
> The certificate chain can produce different results, we have already =20=
> seen this
>
> Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
>
> <graycol.gif>John Bradley ---01/08/2009 08:25:52 AM---Better, thanks =20=
> Mike.
>
> <ecblank.gif>
> From: <ecblank.gif>
> John Bradley <jbradley@mac.com>
> <ecblank.gif>
> To: <ecblank.gif>
> Mike Jones <Michael.Jones@microsoft.com>
> <ecblank.gif>
> Cc: <ecblank.gif>
> "imi@lists.oasis-open.org" <imi@lists.oasis-open.org>
> <ecblank.gif>
> Date: <ecblank.gif>
> 01/08/2009 08:25 AM
> <ecblank.gif>
> Subject: <ecblank.gif>
> Re: [imi] Clarifications to the spec to discuss for our call on =20
> Thursday
>
>
>
> Better, thanks Mike.
>
> For auditing mode cards do we want to say that the IP/STS SHOULD use =20=
> the certificate chain to produce the PPID with a cryptographically =20
> non-invertible function, such as the one used to calculate the PPID =20=
> for p-cards.
>
> If we are going to have the spec say that the selector should send =20
> the PPID for auditing mode cards, I don't want to infer that using =20
> that even with a hash function is better than calculating it from =20
> the site cert chain.
>
> =3Djbradley
> On 7-Jan-09, at 11:52 PM, Mike Jones wrote:
> OK, based on a private discussion on this topic with John, I=92m going =
=20
> to suggest that we change the language =93The IP/STS MAY use this =20
> value as-is or as an input seed to a custom function to derive a =20
> value for the PPID claim=94 to =93The IP/STS SHOULD combine this PPID =20=
> seed value with constant information known to the IP/STS and pass =20
> the combination through a cryptographically non-invertible function, =20=
> such as a cryptographic hash function, to generate the PPID claim =20
> value sent in the signed token=94.
>
> -- 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 =20
> 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 =20
> 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 =20=
> say
> > > > Verisign blindly includes it in its signed response the RP =20
> checking
> > > > the PPID and sig as it would for a p-card could be spoofed if =20=
> it was
> > > > relying solely on those two values.
> > > >
> > > > Including a pre-calculated PPID may make some IP/STS lazy and =20=
> not
> > > > calculate it themselves when they clearly can.
> > > >
> > > > Minimally I think the PPID coming from the selector should be =20=
> 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 =20
> 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 =20
> RP ID.
> > > A user may not want to tell the IdP the name of every site they =20=
> 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 =20=
> required, not required, or optional - and that information is in the =20=
> card and/or IdP metadata (I forget which).
> The RP gets to specify whether or not a specific IdP is required, or =20=
> whether any is acceptable.
> The user gets to select which card (and therefore which IdP) will be =20=
> used.
>
> If a user does not want to use a card that requires disclosure of RP =20=
> identity to the IdP, it can choose another card.
> If the only cards the user has that match the RP policy are cards =20
> that require RP disclosure, the user can go elsewhere.
> As far as I know there is nothing in the selector that tells the =20
> 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 =20
> that matches the required claims but if they have two cards one =20
> auditing and one not they have no easy way to distinguish between =20
> them.
>
> I have to go back and look at how optional auditing mode works that =20=
> is a new one to me.
>
> As near as I can see with current selectors the power is in the =20
> hands of the IdP, unless I am missing something.
>
> =3Djbradley
>
>
>
--Apple-Mail-107--279724132
Content-Type: text/html;
charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable
<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; ">True, I was thinking of =
the 1.5 alg that the selector is using to produce the =
"Client Pseudonym" now. <div><br></div><div>The Cert chain is =
needed for verification but only the client cert is used to produce the =
PPID.</div><div><br></div><div>=3Djbradley</div><div><br><div><br></div><d=
iv><br><div><div>On 8-Jan-09, at 12:08 PM, Anthony Nadalin =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><div><p>The certificate chain can produce different =
results, we have already seen this<br> <br> Anthony Nadalin | Work =
512.838.0085 | Cell 512.289.4122<br> <br> =
<span><graycol.gif></span><font color=3D"#424282">John Bradley =
---01/08/2009 08:25:52 AM---Better, thanks Mike.</font><br> <br> <table =
width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0"> =
<tbody><tr valign=3D"top"><td =
width=3D"1%"><span><ecblank.gif></span><br> <font size=3D"2" =
color=3D"#5F5F5F">From:</font></td><td =
width=3D"100%"><span><ecblank.gif></span><br> <font size=3D"2">John =
Bradley <<a =
href=3D"mailto:jbradley@mac.com";>jbradley@mac.com</a>></font></td></tr> =
<tr valign=3D"top"><td width=3D"1%"><span><ecblank.gif></span><br> =
<font size=3D"2" color=3D"#5F5F5F">To:</font></td><td =
width=3D"100%"><span><ecblank.gif></span><br> <font size=3D"2">Mike =
Jones <<a =
href=3D"mailto:Michael.Jones@microsoft.com";>Michael.Jones@microsoft.com</a=
>></font></td></tr> <tr valign=3D"top"><td =
width=3D"1%"><span><ecblank.gif></span><br> <font size=3D"2" =
color=3D"#5F5F5F">Cc:</font></td><td width=3D"100%" =
valign=3D"middle"><span><ecblank.gif></span><br> <font size=3D"2">"<a =
href=3D"mailto:imi@lists.oasis-open.org";>imi@lists.oasis-open.org</a>" =
<<a =
href=3D"mailto:imi@lists.oasis-open.org";>imi@lists.oasis-open.org</a>></fo=
nt></td></tr> <tr valign=3D"top"><td =
width=3D"1%"><span><ecblank.gif></span><br> <font size=3D"2" =
color=3D"#5F5F5F">Date:</font></td><td =
width=3D"100%"><span><ecblank.gif></span><br> <font =
size=3D"2">01/08/2009 08:25 AM</font></td></tr> <tr valign=3D"top"><td =
width=3D"1%"><span><ecblank.gif></span><br> <font size=3D"2" =
color=3D"#5F5F5F">Subject:</font></td><td =
width=3D"100%"><span><ecblank.gif></span><br> <font size=3D"2">Re: =
[imi] Clarifications to the spec to discuss for our call on =
Thursday</font></td></tr> </tbody></table> </p><hr width=3D"100%" =
size=3D"2" align=3D"left" noshade=3D"" style=3D"color:#8091A5; "><br> =
<br> <br> <font size=3D"4">Better, thanks Mike.</font><br> <br> <font =
size=3D"4">For auditing mode cards do we want to say that the IP/STS =
SHOULD use the certificate chain to produce the PPID with a </font><font =
face=3D"Arial">cryptographically non-invertible function, such as the =
one used to calculate the PPID for p-cards.</font><br> <br> <font =
face=3D"Arial">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.</font><br> <br> <font =
face=3D"Arial">=3Djbradley</font><br> <font size=3D"4">On 7-Jan-09, at =
11:52 PM, Mike Jones wrote:</font><br> <ul> <ul><font color=3D"#1F497D" =
face=3D"Calibri">OK, based on a private discussion on this topic with =
John, I=92m going to suggest that we change the language =93</font><font =
face=3D"Arial">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</font><font =
color=3D"#1F497D" face=3D"Calibri">=94 to =93</font><font =
face=3D"Arial">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</font><font color=3D"#1F497D" =
face=3D"Calibri">=94.</font><br> <font color=3D"#1F497D" face=3D"Calibri">=
</font><br> <font color=3D"#1F497D" face=3D"Calibri"> =
-- Mike</font><br> <font =
color=3D"#1F497D" face=3D"Calibri"> </font><br> <b><font =
face=3D"Tahoma">From:</font></b><font face=3D"Tahoma"> John Bradley =
[</font><a href=3D"mailto:jbradley@mac.com";><u><font color=3D"#0000FF" =
face=3D"Tahoma">mailto:jbradley@mac.com</font></u></a><font =
face=3D"Tahoma">] </font><b><font face=3D"Tahoma"><br> =
Sent:</font></b><font face=3D"Tahoma"> Wednesday, January 07, 2009 1:02 =
PM</font><b><font face=3D"Tahoma"><br> To:</font></b><font =
face=3D"Tahoma"> </font><a =
href=3D"mailto:imi@lists.oasis-open.org";><u><font color=3D"#0000FF" =
face=3D"Tahoma">imi@lists.oasis-open.org</font></u></a><b><font =
face=3D"Tahoma"><br> Subject:</font></b><font face=3D"Tahoma"> Re: [imi] =
Clarifications to the spec to discuss for our call on =
Thursday</font><br> <font size=3D"4" face=3D"Times New Roman"> =
</font><br> <font size=3D"4" face=3D"Times New =
Roman"><snip></font><br> <font size=3D"4" face=3D"Times New Roman">On =
7-Jan-09, at 5:17 PM, Michael McIntosh wrote:</font><br> <font size=3D"4" =
face=3D"Times New Roman"><br> </font><p><font face=3D"Courier New">John =
Bradley <</font><a href=3D"mailto:jbradley@mac.com";><u><font =
color=3D"#0000FF" face=3D"Courier =
New">jbradley@mac.com</font></u></a><font face=3D"Courier New">> wrote =
on 01/07/2009 02:21:00 PM:<br> > <br> > <inline><br> > On 7-Jan-09, =
at 1:18 PM, Michael McIntosh wrote:<br> > <br> > > John Bradley =
<</font><a href=3D"mailto:jbradley@mac.com";><u><font color=3D"#0000FF" =
face=3D"Courier New">jbradley@mac.com</font></u></a><font face=3D"Courier =
New">> wrote on 01/07/2009 11:00:04 AM:<br> > ><br> > > <snip><br> > =
> ><br> > > > However a IP/STS trusting a PPID coming from a selector =
has always<br> > > > made me a bit nervous. I could as an example =
modify the Higgins<br> > > > selector to send arbitrary PPID values in a =
RST. If the IP/STS say<br> > > > Verisign blindly includes it in its =
signed response the RP checking<br> > > > the PPID and sig as it would =
for a p-card could be spoofed if it was<br> > > > relying solely on =
those two values.<br> > > ><br> > > > Including a pre-calculated PPID =
may make some IP/STS lazy and not<br> > > > calculate it themselves when =
they clearly can.<br> > > ><br> > > > Minimally I think the PPID coming =
from the selector should be used<br> > > > as input to some other hash =
function to at-least make spoofing <br> > > more difficult.<br> > > =
><br> > > > I know the spec allows for using the PPID as input to a =
custom<br> > > > function, but I have never seen an explanation of why =
that is a <br> > > good idea.<br> > > ><br> > > > I am OK with always =
including the PPID in the request if someplace<br> > > > we document the =
security issues around PPID in m-cards.<br> > ><br> > > In order for the =
IdP to compute the PPID, it needs to know the RP ID.<br> > > A user may =
not want to tell the IdP the name of every site they visit.<br> > ><br> =
> Agreed that is why we have the two options though they are at the =
<br> > discretion of the card issuer not the user.</font><font size=3D"4" =
face=3D"Times New Roman"><br> </font><font face=3D"Courier New"><br> Not =
completely.<br> 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).<br> The RP gets to =
specify whether or not a specific IdP is required, or whether any is =
acceptable.<br> The user gets to select which card (and therefore which =
IdP) will be used.</font><font size=3D"4" face=3D"Times New Roman"><br> =
</font><font face=3D"Courier New"><br> If a user does not want to use a =
card that requires disclosure of RP identity to the IdP, it can choose =
another card.<br> If the only cards the user has that match the RP =
policy are cards that require RP disclosure, the user can go =
elsewhere.</font><font size=3D"2" face=3D"Courier New"> </font><br> =
<font size=3D"4" face=3D"Times New Roman">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.</font><br> <font size=3D"4" =
face=3D"Times New Roman"> </font><br> <font size=3D"4" face=3D"Times New =
Roman">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.</font><br> <font size=3D"4" face=3D"Times New Roman"> </font><br> =
<font size=3D"4" face=3D"Times New Roman">I have to go back and look at =
how optional auditing mode works that is a new one to me.</font><br> =
<font size=3D"4" face=3D"Times New Roman"> </font><br> <font size=3D"4" =
face=3D"Times New Roman">As near as I can see with current selectors the =
power is in the hands of the IdP, unless I am missing =
something.</font><br> <font size=3D"4" face=3D"Times New Roman"> =
</font><br> <font size=3D"4" face=3D"Times New =
Roman">=3Djbradley</font><br> <font size=3D"4" face=3D"Times New Roman"> =
</font><br> <font size=3D"4" face=3D"Times New Roman"> </font><br> <br> =
</p></ul> </ul> </div></blockquote></div><br></div></div></body></html>=
--Apple-Mail-107--279724132--
--Apple-Mail-108--279724061
Content-Disposition: attachment;
filename=smime.p7s
Content-Type: application/pkcs7-signature;
name=smime.p7s
Content-Transfer-Encoding: base64
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGrzCCAz8w
ggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0
ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcx
KDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0
ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxA
dGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpB
MSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg
UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA
xKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7d
yfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/
p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDow
OKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3Js
MAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgw
DQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A
9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYI
Tq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8wggNoMIIC0aADAgECAhAd94+bIYviuSaQ
w/qU/yWPMA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29u
c3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz
dWluZyBDQTAeFw0wODEyMTIwMTU0MzFaFw0wOTEyMTIwMTU0MzFaMIGfMR8wHQYDVQQDExZUaGF3
dGUgRnJlZW1haWwgTWVtYmVyMR8wHQYJKoZIhvcNAQkBFhBqYnJhZGxleUBtYWMuY29tMR4wHAYJ
KoZIhvcNAQkBFg9qYnJhZGxleUBtZS5jb20xHTAbBgkqhkiG9w0BCQEWDnZlN2p0YkBtYWMuY29t
MRwwGgYJKoZIhvcNAQkBFg12ZTdqdGJAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAxB2GGbZ5p8mVtg16CSDXeF8F3D+5sbs8L4b/YrHt/BvtQdE8GY202cUko/b/rXTUA0JC
XZRDrOiH7ZxcqI4alJNel9AcSLepcdHN4+t2zhvWilm+YF0/r6m/1PikkVT9TWic61IZMpNWIUkk
A+MWzEjChYPefdSMhxikhhMFZ0sv2qPE9pmdaPtD2uF4MwKnIzdZYo+X7rWoaXHIdsZwZDU3HdR5
rVuK5s9xvRED7TZgwE1/yHzHnTbedUWPdNNUlL24Jp3iiVzjZan8zOCn6x4b8O1QPN5b/FOZrerq
FDZ2zhIBsWEcKdIxqIqPdVkrYvEfGBLMe1QIORu0J56L/QIDAQABo10wWzBLBgNVHREERDBCgRBq
YnJhZGxleUBtYWMuY29tgQ9qYnJhZGxleUBtZS5jb22BDnZlN2p0YkBtYWMuY29tgQ12ZTdqdGJA
bWUuY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEADhjvX5w/BXN7OL5y1ZfydfmJ
RKezNqugUDf8XbKmmMR/o+vjx395pBpO9QF8hQwtKNDuvoxLTNDMWdcCNbvaEpqREXc7liV9FfA5
ndAB1VgDqYDjY9M9LU54LH8uqEx7+pX6qa6KoR8eRHby9zi+iuSkJ4GLI59RBnVI54x4/acxggMQ
MIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5
KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQHfeP
myGL4rkmkMP6lP8ljzAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG
CSqGSIb3DQEJBTEPFw0wOTAxMDgxNjAyMjZaMCMGCSqGSIb3DQEJBDEWBBRDn/OglCu7MH87Mj1o
Fjf3SKGK6DCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl
IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWls
IElzc3VpbmcgQ0ECEB33j5shi+K5JpDD+pT/JY8wgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYD
VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMj
VGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEB33j5shi+K5JpDD+pT/JY8wDQYJ
KoZIhvcNAQEBBQAEggEAJlFEDGjaaqMy9OT8zHJmGEnv7DNmrzLAnf83qQNVwqw7PFYsVEjLB+D7
t2leWHJIWLE64TG0RdkCtRL1euvRWxh/WK7qyxEXG3FX12z1AuRJvaeETP1BCofFE16rFyYS5b79
keSnJ4Twlf9EHcLalHz+mDGt8XDTNuc+iuzr7yY7CW2MJz9qrgT0uRwaLZM7wzsUSInNu0VR4ftb
zTZ3RPQQiw1TRep8IP/owZuXyQuPftdcpHtT2T4KVTHPi2sZsBycr4Fi4Nm+T7+LxgRD/F2z4rck
jpBWSrXV6/e0kIJpp5VffLjzAwwXDmosxKWDHAv8levmIDW6Jl9MAaMV9gAAAAAAAA==
--Apple-Mail-108--279724061--
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]