[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-102--285624179 Content-Type: multipart/alternative; boundary=Apple-Mail-101--285624301 --Apple-Mail-101--285624301 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable 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 non-=20= invertible function, such as the one used to calculate the PPID for p-=20= cards. If we are going to have the spec say that the selector should send the =20= PPID for auditing mode cards, I don't want to infer that using that =20 even with a hash function is better than calculating it from the site =20= 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. > > -- =20 > 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 =20 > Higgins > > > > selector to send arbitrary PPID values in a RST. If the IP/=20 > STS 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-101--285624301 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; ">Better, thanks = Mike.<div><br></div><div>For auditing mode cards do we want to say that = the IP/STS SHOULD use the certificate chain to produce the PPID with = a <span class=3D"Apple-style-span" style=3D"font-family: Arial; = font-size: 13px; ">cryptographically non-invertible function, such as = the one used to calculate the PPID for = p-cards.</span></div><div><font class=3D"Apple-style-span" face=3D"Arial" = size=3D"3"><span class=3D"Apple-style-span" style=3D"font-size: = 13px;"><br></span></font></div><div><font class=3D"Apple-style-span" = face=3D"Arial" size=3D"3"><span class=3D"Apple-style-span" = style=3D"font-size: 13px;">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.</span></font></div><div><font class=3D"Apple-style-span" = face=3D"Arial" size=3D"3"><span class=3D"Apple-style-span" = style=3D"font-size: 13px;"><br></span></font></div><div><font = class=3D"Apple-style-span" face=3D"Arial" size=3D"3"><span = class=3D"Apple-style-span" style=3D"font-size: = 13px;">=3Djbradley<br></span></font><div><div>On 7-Jan-09, at 11:52 PM, = Mike Jones wrote:</div><br class=3D"Apple-interchange-newline"><blockquote= type=3D"cite"><span class=3D"Apple-style-span" style=3D"border-collapse: = separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; = font-style: normal; font-variant: normal; font-weight: normal; = letter-spacing: normal; line-height: normal; orphans: 2; text-align: = auto; text-indent: 0px; text-transform: none; white-space: normal; = widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; = -webkit-border-vertical-spacing: 0px; = -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: = auto; -webkit-text-stroke-width: 0; "><div lang=3D"EN-US" link=3D"blue" = vlink=3D"purple" style=3D"word-wrap: break-word; -webkit-nbsp-mode: = space; -webkit-line-break: after-white-space; "><div = class=3D"Section1"><div style=3D"margin-top: 0in; margin-right: 0in; = margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: = 'Times New Roman', serif; "><span style=3D"font-size: 11pt; font-family: = Calibri, sans-serif; color: rgb(31, 73, 125); ">OK, based on a private = discussion on this topic with John, I=92m going to suggest that we = change the language =93</span><span style=3D"font-size: 10pt; = font-family: Arial, sans-serif; ">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</span><span style=3D"font-size: 11pt; font-family: Calibri, = sans-serif; color: rgb(31, 73, 125); ">=94 to =93</span><span = style=3D"font-size: 10pt; font-family: Arial, sans-serif; ">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</span><span = style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: = rgb(31, 73, 125); ">=94.<o:p></o:p></span></div><div style=3D"margin-top: = 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; = font-size: 12pt; font-family: 'Times New Roman', serif; "><span = style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: = rgb(31, 73, 125); "><o:p> </o:p></span></div><div = style=3D"margin-top: 0in; margin-right: 0in; margin-left: 0in; = margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New = Roman', serif; "><span style=3D"font-size: 11pt; font-family: Calibri, = sans-serif; color: rgb(31, 73, 125); = "> = &n= bsp; &nbs= p; = &n= bsp; -- Mike<o:p></o:p></span></div><div style=3D"margin-top: 0in; = margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: = 12pt; font-family: 'Times New Roman', serif; "><span style=3D"font-size: = 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); = "><o:p> </o:p></span></div><div><div style=3D"border-right-style: = none; border-bottom-style: none; border-left-style: none; border-width: = initial; border-color: initial; border-top-style: solid; = border-top-color: rgb(181, 196, 223); border-top-width: 1pt; = padding-top: 3pt; padding-right: 0in; padding-bottom: 0in; padding-left: = 0in; "><div style=3D"margin-top: 0in; margin-right: 0in; margin-left: = 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New = Roman', serif; "><b><span style=3D"font-size: 10pt; font-family: Tahoma, = sans-serif; ">From:</span></b><span style=3D"font-size: 10pt; = font-family: Tahoma, sans-serif; "><span = class=3D"Apple-converted-space"> </span>John Bradley [<a = href=3D"mailto:jbradley@mac.com"; style=3D"color: blue; text-decoration: = underline; ">mailto:jbradley@mac.com</a>]<span = class=3D"Apple-converted-space"> </span><br><b>Sent:</b><span = class=3D"Apple-converted-space"> </span>Wednesday, January 07, 2009 = 1:02 PM<br><b>To:</b><span class=3D"Apple-converted-space"> </span><a= href=3D"mailto:imi@lists.oasis-open.org"; style=3D"color: blue; = text-decoration: underline; = ">imi@lists.oasis-open.org</a><br><b>Subject:</b><span = class=3D"Apple-converted-space"> </span>Re: [imi] Clarifications to = the spec to discuss for our call on = Thursday<o:p></o:p></span></div></div></div><div style=3D"margin-top: = 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; = font-size: 12pt; font-family: 'Times New Roman', serif; = "><o:p> </o:p></div><div style=3D"margin-top: 0in; margin-right: = 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; = font-family: 'Times New Roman', serif; = "><snip><o:p></o:p></div><div><div><div style=3D"margin-top: 0in; = margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: = 12pt; font-family: 'Times New Roman', serif; ">On 7-Jan-09, at 5:17 PM, = Michael McIntosh wrote:<o:p></o:p></div></div><div style=3D"margin-top: = 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; = font-size: 12pt; font-family: 'Times New Roman', serif; = "><br><br><o:p></o:p></div><div><p style=3D"margin-right: 0in; = margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', = serif; "><tt style=3D"font-family: 'Courier New'; "><span = style=3D"font-size: 10pt; ">John Bradley <<a = href=3D"mailto:jbradley@mac.com"; style=3D"color: blue; text-decoration: = underline; ">jbradley@mac.com</a>> wrote on 01/07/2009 02:21:00 = PM:</span></tt><br><tt style=3D"font-family: 'Courier New'; "><span = style=3D"font-size: 10pt; ">><span = class=3D"Apple-converted-space"> </span></span></tt><span = style=3D"font-size: 10pt; font-family: 'Courier New'; "><br><tt = style=3D"font-family: 'Courier New'; ">> <inline></tt><br><tt = style=3D"font-family: 'Courier New'; ">> On 7-Jan-09, at 1:18 PM, = Michael McIntosh wrote:</tt><br><tt style=3D"font-family: 'Courier New'; = ">><span class=3D"Apple-converted-space"> </span></tt><br><tt = style=3D"font-family: 'Courier New'; ">> > John Bradley <<a = href=3D"mailto:jbradley@mac.com"; style=3D"color: blue; text-decoration: = underline; ">jbradley@mac.com</a>> wrote on 01/07/2009 11:00:04 = AM:</tt><br><tt style=3D"font-family: 'Courier New'; ">> ></tt><br><tt = style=3D"font-family: 'Courier New'; ">> > <snip></tt><br><tt = style=3D"font-family: 'Courier New'; ">> > ></tt><br><tt = style=3D"font-family: 'Courier New'; ">> > > However a IP/STS trusting a = PPID coming from a selector has always</tt><br><tt style=3D"font-family: = 'Courier New'; ">> > > made me a bit nervous. I could as an = example modify the Higgins</tt><br><tt style=3D"font-family: 'Courier = New'; ">> > > selector to send arbitrary PPID values in a RST. If = the IP/STS say</tt><br><tt style=3D"font-family: 'Courier New'; ">> > > = Verisign blindly includes it in its signed response the RP = checking</tt><br><tt style=3D"font-family: 'Courier New'; ">> > > the = PPID and sig as it would for a p-card could be spoofed if it = was</tt><br><tt style=3D"font-family: 'Courier New'; ">> > > relying = solely on those two values.</tt><br><tt style=3D"font-family: 'Courier = New'; ">> > ></tt><br><tt style=3D"font-family: 'Courier New'; ">> > > = Including a pre-calculated PPID may make some IP/STS lazy and = not</tt><br><tt style=3D"font-family: 'Courier New'; ">> > > calculate = it themselves when they clearly can.</tt><br><tt style=3D"font-family: = 'Courier New'; ">> > ></tt><br><tt style=3D"font-family: 'Courier New'; = ">> > > Minimally I think the PPID coming from the selector should be = used</tt><br><tt style=3D"font-family: 'Courier New'; ">> > > as input = to some other hash function to at-least make spoofing </tt><br><tt = style=3D"font-family: 'Courier New'; ">> > more difficult.</tt><br><tt = style=3D"font-family: 'Courier New'; ">> > ></tt><br><tt = style=3D"font-family: 'Courier New'; ">> > > I know the spec allows for = using the PPID as input to a custom</tt><br><tt style=3D"font-family: = 'Courier New'; ">> > > function, but I have never seen an = explanation of why that is a </tt><br><tt style=3D"font-family: = 'Courier New'; ">> > good idea.</tt><br><tt style=3D"font-family: = 'Courier New'; ">> > ></tt><br><tt style=3D"font-family: 'Courier New'; = ">> > > I am OK with always including the PPID in the request if = someplace</tt><br><tt style=3D"font-family: 'Courier New'; ">> > > we = document the security issues around PPID in m-cards.</tt><br><tt = style=3D"font-family: 'Courier New'; ">> ></tt><br><tt = style=3D"font-family: 'Courier New'; ">> > In order for the IdP to = compute the PPID, it needs to know the RP ID.</tt><br><tt = style=3D"font-family: 'Courier New'; ">> > A user may not want to tell = the IdP the name of every site they visit.</tt><br><tt = style=3D"font-family: 'Courier New'; ">> ></tt><br><tt = style=3D"font-family: 'Courier New'; ">> Agreed that is why we have the = two options though they are at the </tt><br><tt = style=3D"font-family: 'Courier New'; ">> discretion of the card issuer = not the user.</tt></span><br><br><tt style=3D"font-family: 'Courier = New'; "><span style=3D"font-size: 10pt; ">Not = completely.</span></tt><br><tt style=3D"font-family: 'Courier New'; = "><span style=3D"font-size: 10pt; ">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).</span></tt><br><tt style=3D"font-family: 'Courier New'; "><span = style=3D"font-size: 10pt; ">The RP gets to specify whether or not a = specific IdP is required, or whether any is = acceptable.</span></tt><br><tt style=3D"font-family: 'Courier New'; = "><span style=3D"font-size: 10pt; ">The user gets to select which card = (and therefore which IdP) will be used.</span></tt><br><br><tt = style=3D"font-family: 'Courier New'; "><span style=3D"font-size: 10pt; = ">If a user does not want to use a card that requires disclosure of RP = identity to the IdP, it can choose another card.</span></tt><br><tt = style=3D"font-family: 'Courier New'; "><span style=3D"font-size: 10pt; = ">If the only cards the user has that match the RP policy are cards that = require RP disclosure, the user can go elsewhere.</span></tt><span = class=3D"apple-style-span"><span style=3D"font-size: 9pt; font-family: = 'Courier New'; = "> </span></span><o:p></o:p></p></div></div><div><div = style=3D"margin-top: 0in; margin-right: 0in; margin-left: 0in; = margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New = Roman', serif; ">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.<o:p></o:p></div></div><div><div style=3D"margin-top: 0in; = margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: = 12pt; font-family: 'Times New Roman', serif; = "><o:p> </o:p></div></div><div><div style=3D"margin-top: 0in; = margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: = 12pt; font-family: 'Times New Roman', serif; ">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.<o:p></o:p></div></div><div><div style=3D"margin-top: 0in; = margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: = 12pt; font-family: 'Times New Roman', serif; = "><o:p> </o:p></div></div><div><div style=3D"margin-top: 0in; = margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: = 12pt; font-family: 'Times New Roman', serif; ">I have to go back and = look at how optional auditing mode works that is a new one to = me.<o:p></o:p></div></div><div><div style=3D"margin-top: 0in; = margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: = 12pt; font-family: 'Times New Roman', serif; = "><o:p> </o:p></div></div><div><div style=3D"margin-top: 0in; = margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: = 12pt; font-family: 'Times New Roman', serif; ">As near as I can see with = current selectors the power is in the hands of the IdP, unless I = am missing something.<o:p></o:p></div></div><div><div style=3D"margin-top:= 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; = font-size: 12pt; font-family: 'Times New Roman', serif; = "><o:p> </o:p></div></div><div><div style=3D"margin-top: 0in; = margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: = 12pt; font-family: 'Times New Roman', serif; = ">=3Djbradley<o:p></o:p></div></div><div><div style=3D"margin-top: 0in; = margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: = 12pt; font-family: 'Times New Roman', serif; = "><o:p> </o:p></div></div><div><div style=3D"margin-top: 0in; = margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: = 12pt; font-family: 'Times New Roman', serif; = "> <o:p></o:p></div></div></div></div></span></blockquote></div><br><= /div></body></html>= --Apple-Mail-101--285624301-- --Apple-Mail-102--285624179 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 CSqGSIb3DQEJBTEPFw0wOTAxMDgxNDI0MDZaMCMGCSqGSIb3DQEJBDEWBBToE8+AW+lAQ4f0REn7 KgagKxw/MTCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWls IElzc3VpbmcgQ0ECEB33j5shi+K5JpDD+pT/JY8wgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMj VGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEB33j5shi+K5JpDD+pT/JY8wDQYJ KoZIhvcNAQEBBQAEggEAD0mYS+ZKQXGka1wrIKA73BtSmB8cruFeHg3VC7ZQNKtNCnQL/Y26Pt7a 15dmRxKjG7HrdYReAsKioC/0b+slIJu4HFkUrsQTclozdkyD1edpkudwNk6P8hj0OkuvIQtt7AcL pk2ELaA7+sI0oIGxdhBbsge/NkvLKqBgEYJMBCw0ld35D4aUPTyXolCb5z28SxINiGMCLV5j0ZYR dBaoQIxudePYPk6ez3gezv4XuIBOj0JRJDfD+tj2cQsVp+M941bJxjIoAB8Nz1gKKZP68VnMh+la DTsbiVrnWmyC1S5NKFhlo0dJbIJGRJAi6eHzftSi9/89L5Nd8yZo0IKEjgAAAAAAAA== --Apple-Mail-102--285624179--
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]