[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xri] FW: New Version Notification - draft-hammer-hostmeta-09.txt
--Apple-Mail-104-70296524 Content-Type: multipart/alternative; boundary=Apple-Mail-103-70296350 --Apple-Mail-103-70296350 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii No criticism of Magic signatures. If all JRD were required to be signed it would be perfect. =20 The problem will be that resolving applications will ask for a JRD and = potentially get it back in two forms, one with an enveloping signature. It complicates the processing for applications not caring about the = signature. That is the nice thing about the enveloped signature in XML. It is a trade off, for most things using magic signature it is not a = issue. For the JRD use case I think it adds complexity. It is something Nat and I have been looking at when considering Magic = signature for use in openID artifact binding. Full XML canonicalization is too complex. We did constrain that in XRD = signatures. =20 Base64 encoding is not bad but is not perfect for all situations. I = think a simple form of enveloped signature should be possible for JSON = though I am not volunteering to develop it. Where I think that you don't get value by using Magic Signature to sign = a host-meta file is that it simply supports direct key comparison from a = XRD. In most cases that would be a bit circular as the XRD is resolved via = host-meta. We need to clearly understand what is attempting to be achieved by = signing a host-meta file and how that fits into a desirable trust model. It may be that it doesn't achieve anything more than retrieving the = host-meta over https:. If you want to verify that you have the correct = file you can still use Subject and put in an acct: URI like = acct:@example.com. =20 I think it was Google that had some use cases for third party signing of = host-meta. Unless we really understand what we want, it is simpler to have one = format JRD. John B. On 2010-05-24, at 3:18 PM, Bob Wyman wrote: > John Bradley <ve7jtb@ve7jtb.com> wrote: > > [Magic Signatures] adds complexity [by] requiring=20 > > the unpacking of a base64 encoded file.... > Actually, I think that Magic Signatures *reduces* complexity to the = point where it really can't get much simpler. The base64 encoding = removes the need for the kind of bizarrely complex canonicalization code = that is normally required by signature schemes. > When trying to figure out why it is that people typically consider = signing to be a "complex" problem, it became apparent that for many, = many developers, the problem of canonicalization was significant. Thus, = the trivially simple base64 approach (proposed by Ben Laurie) was = adopted to make canonicalization as easy as possible. The base64 = approach also has the nice attribute that the base64 blobs will = typically pass through any of the many XML parsing systems without being = modified in such a way that data is lost.=20 >=20 > John, can you propose a more simple means of doing canonicalization = than the one defined by Magic Signatures? If you've got something = simpler which is also robust to XML parsers, then I'm sure that there = would be significant interest in considering it. >=20 > bob wyman >=20 >=20 > On Mon, May 24, 2010 at 2:28 PM, John Bradley <ve7jtb@ve7jtb.com> = wrote: > +1 to the change. >=20 > I think especially with JRD it is unclear how a signature relates to = <Host> especially given that Magic signatures use raw keys as opposed to = X509 certificates. >=20 > In many ways magic signature a good thing however it doesn't solve the = trust bootstrap problem, and adds complexity requiring the unpacking of = a base64 encoded file. >=20 > I think the trust model for host-meta needs more thought. >=20 > John B. >=20 > On 2010-05-24, at 2:11 PM, Eran Hammer-Lahav wrote: >=20 > > The <Host> element as currently specified adds no value to any of = the use cases host-meta is intended for. The only reason why it was = originally added was to support signatures. At this point it is far from = clear how it will actually be used, how to address multiple hosts, and = what impact will a JSON serialization will have on signatures = (especially when considering "magic signatures"). > > > > It is a part of the spec no one really cares much about, and = removing it doesn't prevent anyone from specifying it elsewhere, where = it is actually used. > > > > As for last stage, I'm not done with the document and planning on = making significant changes to LRDD and integrating them into the same = spec. This is based on feedback received over the last couple of weeks. > > > > Host-meta didn't even reach IETF last call yet. > > > > EHL > > > >> -----Original Message----- > >> From: Breno de Medeiros [mailto:breno@google.com] > >> Sent: Monday, May 24, 2010 10:56 AM > >> To: Eran Hammer-Lahav > >> Cc: xri@lists.oasis-open.org; webfinger@googlegroups.com > >> Subject: Re: [xri] FW: New Version Notification - = draft-hammer-hostmeta- > >> 09.txt > >> > >> -1 to this change. > >> > >> Can you explain why the simplification is worth the cost of making = a last- > >> minute change and sowing uncertainty at this last stage? > >> > >> On Mon, May 24, 2010 at 10:49, Eran Hammer-Lahav > >> <eran@hueniverse.com> wrote: > >>> They can do whatever they want, as long as it is valid according = to the XRD > >> schema. Host-meta leaves <Subject> and <Alias> undefined and not > >> recommended. > >>> > >>> EHL > >>> > >>>> -----Original Message----- > >>>> From: Breno de Medeiros [mailto:breno@google.com] > >>>> Sent: Monday, May 24, 2010 10:21 AM > >>>> To: Eran Hammer-Lahav > >>>> Cc: xri@lists.oasis-open.org; webfinger@googlegroups.com > >>>> Subject: Re: [xri] FW: New Version Notification - > >>>> draft-hammer-hostmeta- 09.txt > >>>> > >>>> I suspect people will want to write a <Subject> instead of = <hm:Host> > >>>> now that it's gone. :) > >>>> > >>>> On Mon, May 24, 2010 at 00:52, Eran Hammer-Lahav > >>>> <eran@hueniverse.com> wrote: > >>>>> After much (re)deliberation and discussions, I've decided to = drop > >>>>> the > >>>> <Host> element from host-meta. The two reasons why it was there = were: > >>>>> > >>>>> 1. make host-meta self-contained so it can be obtained via other > >>>>> means than /.well-known/host-meta 2. provide a subject for > >>>>> signatures > >>>>> > >>>>> Since there are no use cases for #1, and #2 has failed to > >>>>> materialize after > >>>> more than a year of discussions (still no signature profile > >>>> published), I have decided that for the sake of simplicity and > >>>> practicality to remove the element. host-meta doesn't address > >>>> security and it should not provide a hook for future security > >>>> profiles - that's their job. Those who find a need for expressing = the > >>>> subject of a host-meta XRD (or JRD) can add it back in their own = spec (or > >> make up something else). > >>>>> > >>>>> -09 dropped the element. > >>>>> > >>>>> Note that there is going to be a -10 coming out shortly which > >>>>> merges LRDD > >>>> back into host-meta, dropping links from HTTP headers and HTML = bodies > >>>> (which don't have any driving use cases). > >>>>> > >>>>> EHL > >>>>> > >>>>> > >>>>> -----Original Message----- > >>>>> From: Internet-Draft@ietf.org [mailto:Internet-Draft@ietf.org] > >>>>> Sent: Monday, May 24, 2010 12:45 AM > >>>>> To: Eran Hammer-Lahav; draft-hammer-hostmeta@tools.ietf.org; > >>>>> stpeter@stpeter.im > >>>>> Subject: New Version Notification - draft-hammer-hostmeta-09.txt > >>>>> > >>>>> New version (-09) has been submitted for draft-hammer-hostmeta- > >> 09.txt. > >>>>> http://www.ietf.org/internet-drafts/draft-hammer-hostmeta-09.txt > >>>>> > >>>>> > >>>>> Diff from previous version: > >>>>> http://tools.ietf.org/rfcdiff?url2=3Ddraft-hammer-hostmeta-09 > >>>>> > >>>>> IETF Secretariat. > >>>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> --Breno > >>>> > >>>> +1 (650) 214-1007 desk > >>>> +1 (408) 212-0135 (Grand Central) > >>>> MTV-41-3 : 383-A > >>>> PST (GMT-8) / PDT(GMT-7) > >>> > >> > >> > >> > >> -- > >> --Breno > >> > >> +1 (650) 214-1007 desk > >> +1 (408) 212-0135 (Grand Central) > >> MTV-41-3 : 383-A > >> PST (GMT-8) / PDT(GMT-7) >=20 >=20 --Apple-Mail-103-70296350 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii <html><head></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">No = criticism of Magic signatures.<div><br></div><div>If all JRD were = required to be signed it would be perfect. = </div><div><br></div><div>The problem will be that resolving = applications will ask for a JRD and potentially get it back in two = forms, one with an enveloping signature.</div><div>It complicates the = processing for applications not caring about the = signature.</div><div><br></div><div>That is the nice thing about the = enveloped signature in XML.</div><div><br></div><div>It is a trade off, = for most things using magic signature it is not a issue. = For the JRD use case I think it adds = complexity.</div><div><br></div><div>It is something Nat and I have been = looking at when considering Magic signature for use in openID artifact = binding.</div><div><br></div><div>Full XML canonicalization is too = complex. We did constrain that in XRD signatures. = </div><div><br></div><div>Base64 encoding is not bad but is not = perfect for all situations. I think a simple form of enveloped = signature should be possible for JSON though I am not volunteering to = develop it.</div><div><br></div><div>Where I think that you don't get = value by using Magic Signature to sign a host-meta file is that it = simply supports direct key comparison from a XRD.</div><div>In most = cases that would be a bit circular as the XRD is resolved via = host-meta.</div><div><br></div><div>We need to clearly understand what = is attempting to be achieved by signing a host-meta file and how that = fits into a desirable trust model.</div><div><br></div><div>It may be = that it doesn't achieve anything more than retrieving the host-meta over = https:. If you want to verify that you have the correct file you = can still use Subject and put in an acct: URI like acct:@example.com. = </div><div><br></div><div>I think it was Google that had = some use cases for third party signing of = host-meta.</div><div><br></div><div>Unless we really understand what we = want, it is simpler to have one format = JRD.</div><div><br></div><div>John B.</div><div><br></div><div><div>On = 2010-05-24, at 3:18 PM, Bob Wyman wrote:</div><br = class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><meta = http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf-8">John = Bradley <span dir=3D"ltr"><<a = href=3D"mailto:ve7jtb@ve7jtb.com";>ve7jtb@ve7jtb.com</a>></span> wr= ote:<br>> [Magic Signatures] <meta http-equiv=3D"content-type" = content=3D"text/html; charset=3Dutf-8">adds complexity [by] = requiring <div> > the unpacking of a base64 encoded file....<br><div>Actually, I = think that Magic Signatures *reduces* complexity to the point where it = really can't get much simpler. The base64 encoding removes the need for = the kind of bizarrely complex canonicalization code that is normally = required by signature schemes.</div> <div>When trying to figure out why it is that people typically consider = signing to be a "complex" problem, it became apparent that for many, = many developers, the problem of canonicalization was significant. Thus, = the trivially simple base64 approach (proposed by Ben Laurie) was = adopted to make canonicalization as easy as possible. The base64 = approach also has the nice attribute that the base64 blobs will = typically pass through any of the many XML parsing systems without being = modified in such a way that data is lost. </div> <div><br></div><div>John, can you propose a more simple means of doing = canonicalization than the one defined by Magic Signatures? If you've got = something simpler which is also robust to XML parsers, then I'm sure = that there would be significant interest in considering it.</div> <div><br></div><div>bob wyman</div><div><br></div><div><br><div = class=3D"gmail_quote">On Mon, May 24, 2010 at 2:28 PM, John Bradley = <span dir=3D"ltr"><<a = href=3D"mailto:ve7jtb@ve7jtb.com";>ve7jtb@ve7jtb.com</a>></span> = wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 = .8ex;border-left:1px #ccc solid;padding-left:1ex;">+1 to the change.<br> <br> I think especially with JRD it is unclear how a signature relates to = <Host> especially given that Magic signatures use raw keys as = opposed to X509 certificates.<br> <br> In many ways magic signature a good thing however it doesn't solve the = trust bootstrap problem, and adds complexity requiring the = unpacking of a base64 encoded file.<br> <br> I think the trust model for host-meta needs more thought.<br> <br> John B.<br> <div><div></div><div class=3D"h5"><br> On 2010-05-24, at 2:11 PM, Eran Hammer-Lahav wrote:<br> <br> > The <Host> element as currently specified adds no value to = any of the use cases host-meta is intended for. The only reason why it = was originally added was to support signatures. At this point it is far = from clear how it will actually be used, how to address multiple hosts, = and what impact will a JSON serialization will have on signatures = (especially when considering "magic signatures").<br> ><br> > It is a part of the spec no one really cares much about, and = removing it doesn't prevent anyone from specifying it elsewhere, where = it is actually used.<br> ><br> > As for last stage, I'm not done with the document and planning on = making significant changes to LRDD and integrating them into the same = spec. This is based on feedback received over the last couple of = weeks.<br> ><br> > Host-meta didn't even reach IETF last call yet.<br> ><br> > EHL<br> ><br> >> -----Original Message-----<br> >> From: Breno de Medeiros [mailto:<a = href=3D"mailto:breno@google.com";>breno@google.com</a>]<br> >> Sent: Monday, May 24, 2010 10:56 AM<br> >> To: Eran Hammer-Lahav<br> >> Cc: <a = href=3D"mailto:xri@lists.oasis-open.org";>xri@lists.oasis-open.org</a>; = <a = href=3D"mailto:webfinger@googlegroups.com";>webfinger@googlegroups.com</a><= br> >> Subject: Re: [xri] FW: New Version Notification - = draft-hammer-hostmeta-<br> >> 09.txt<br> >><br> >> -1 to this change.<br> >><br> >> Can you explain why the simplification is worth the cost of = making a last-<br> >> minute change and sowing uncertainty at this last stage?<br> >><br> >> On Mon, May 24, 2010 at 10:49, Eran Hammer-Lahav<br> >> <<a = href=3D"mailto:eran@hueniverse.com";>eran@hueniverse.com</a>> = wrote:<br> >>> They can do whatever they want, as long as it is valid = according to the XRD<br> >> schema. Host-meta leaves <Subject> and <Alias> = undefined and not<br> >> recommended.<br> >>><br> >>> EHL<br> >>><br> >>>> -----Original Message-----<br> >>>> From: Breno de Medeiros [mailto:<a = href=3D"mailto:breno@google.com";>breno@google.com</a>]<br> >>>> Sent: Monday, May 24, 2010 10:21 AM<br> >>>> To: Eran Hammer-Lahav<br> >>>> Cc: <a = href=3D"mailto:xri@lists.oasis-open.org";>xri@lists.oasis-open.org</a>; = <a = href=3D"mailto:webfinger@googlegroups.com";>webfinger@googlegroups.com</a><= br> >>>> Subject: Re: [xri] FW: New Version Notification -<br> >>>> draft-hammer-hostmeta- 09.txt<br> >>>><br> >>>> I suspect people will want to write a <Subject> = instead of <hm:Host><br> >>>> now that it's gone. :)<br> >>>><br> >>>> On Mon, May 24, 2010 at 00:52, Eran Hammer-Lahav<br> >>>> <<a = href=3D"mailto:eran@hueniverse.com";>eran@hueniverse.com</a>> = wrote:<br> >>>>> After much (re)deliberation and discussions, I've = decided to drop<br> >>>>> the<br> >>>> <Host> element from host-meta. The two reasons = why it was there were:<br> >>>>><br> >>>>> 1. make host-meta self-contained so it can be = obtained via other<br> >>>>> means than /.well-known/host-meta 2. provide a = subject for<br> >>>>> signatures<br> >>>>><br> >>>>> Since there are no use cases for #1, and #2 has = failed to<br> >>>>> materialize after<br> >>>> more than a year of discussions (still no signature = profile<br> >>>> published), I have decided that for the sake of = simplicity and<br> >>>> practicality to remove the element. host-meta doesn't = address<br> >>>> security and it should not provide a hook for future = security<br> >>>> profiles - that's their job. Those who find a need for = expressing the<br> >>>> subject of a host-meta XRD (or JRD) can add it back in = their own spec (or<br> >> make up something else).<br> >>>>><br> >>>>> -09 dropped the element.<br> >>>>><br> >>>>> Note that there is going to be a -10 coming out = shortly which<br> >>>>> merges LRDD<br> >>>> back into host-meta, dropping links from HTTP headers = and HTML bodies<br> >>>> (which don't have any driving use cases).<br> >>>>><br> >>>>> EHL<br> >>>>><br> >>>>><br> >>>>> -----Original Message-----<br> >>>>> From: <a = href=3D"mailto:Internet-Draft@ietf.org";>Internet-Draft@ietf.org</a> = [mailto:<a = href=3D"mailto:Internet-Draft@ietf.org";>Internet-Draft@ietf.org</a>]<br> >>>>> Sent: Monday, May 24, 2010 12:45 AM<br> >>>>> To: Eran Hammer-Lahav; <a = href=3D"mailto:draft-hammer-hostmeta@tools.ietf.org";>draft-hammer-hostmeta= @tools.ietf.org</a>;<br> >>>>> <a = href=3D"mailto:stpeter@stpeter.im";>stpeter@stpeter.im</a><br> >>>>> Subject: New Version Notification - = draft-hammer-hostmeta-09.txt<br> >>>>><br> >>>>> New version (-09) has been submitted for = draft-hammer-hostmeta-<br> >> 09.txt.<br> >>>>> <a = href=3D"http://www.ietf.org/internet-drafts/draft-hammer-hostmeta-09.txt"; = target=3D"_blank">http://www.ietf.org/internet-drafts/draft-hammer-hostmet= a-09.txt</a><br> >>>>><br> >>>>><br> >>>>> Diff from previous version:<br> >>>>> <a = href=3D"http://tools.ietf.org/rfcdiff?url2=3Ddraft-hammer-hostmeta-09"; = target=3D"_blank">http://tools.ietf.org/rfcdiff?url2=3Ddraft-hammer-hostme= ta-09</a><br> >>>>><br> >>>>> IETF Secretariat.<br> >>>>><br> >>>><br> >>>><br> >>>><br> >>>> --<br> >>>> --Breno<br> >>>><br> >>>> +1 (650) 214-1007 desk<br> >>>> +1 (408) 212-0135 (Grand Central)<br> >>>> MTV-41-3 : 383-A<br> >>>> PST (GMT-8) / PDT(GMT-7)<br> >>><br> >><br> >><br> >><br> >> --<br> >> --Breno<br> >><br> >> +1 (650) 214-1007 desk<br> >> +1 (408) 212-0135 (Grand Central)<br> >> MTV-41-3 : 383-A<br> >> PST (GMT-8) / PDT(GMT-7)<br> <br> </div></div></blockquote></div><br></div></div> </blockquote></div><br></body></html>= --Apple-Mail-103-70296350-- --Apple-Mail-104-70296524 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO9TCCBwsw ggXzoAMCAQICAgZDMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTAwMzE3MTM0NDQ1WhcNMTIwMzE4MTE1NTExWjCBzTEgMB4GA1UEDRMXMTY1NTU1LTJHU3FU T1ZUbkk4OHhOSW4xCzAJBgNVBAYTAkNMMSIwIAYDVQQIExlNZXRyb3BvbGl0YW5hIGRlIFNhbnRp YWdvMREwDwYDVQQHEwhWaXRhY3VyYTEtMCsGA1UECxMkU3RhcnRDb20gVmVyaWZpZWQgQ2VydGlm aWNhdGUgTWVtYmVyMRUwEwYDVQQDEwxKb2huIEJyYWRsZXkxHzAdBgkqhkiG9w0BCQEWEGpicmFk bGV5QG1hYy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDB7DXf6x80dsJiB9B9 Ds4cBQdA+9bNuZMBeXkUAHrvYH2taw6y8fcadbhgk92FyPiCbsHtB1VTaJThaMqtXuTkS4r5Sfb8 k5kboz3OQVPMmrOJIUpaoDP2heKEhMUSL6ev9CvsuYs+XXe7f9vY3w/A8cVg/NoOXbdqKXbWOMMd NSdg7uJWSsmpqILFzQsumwqVH24tYX0sqvpJy/r+pc84j6QM+Ew0B9bz3OkEMafjcCeGRfdsQnLB +rIR8BPDeeKRP6a5e8Lf6slUQ3s/rh33otnkNaz6DMLTJrj0qoAD7FxB7LlLalIjrg08BNZDJUQK 7zTlNxkPqVHVTg3H0OG/AgMBAAGjggMyMIIDLjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNV HSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFMjJGKHWsNb6VU54Wkktqcu2on3B MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MFQGA1UdEQRNMEuBEGpicmFkbGV5QG1h Yy5jb22BEXZlN2p0YkB2ZTdqdGIuY29tgRNqYnJhZGxleUB3aW5nYWEuY29tgQ9qYnJhZGxleUBt ZS5jb20wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQIBMIIBIDAuBggrBgEFBQcCARYi aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYBBQUHAgIwgaowFBYNU3RhcnRD b20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNlZSBzZWN0aW9uICpMZWdhbCBMaW1p dGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBh dmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBa MCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMCugKaAnhiVodHRw Oi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsG AQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYI KwYBBQUHMAKGNmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEF BQADggEBAHu8WZHdSu+I5GMzGDrkxFVUzZ2JAcwzgSscYNFX2CFJlU8ncC+/E5Y18oiGcIR9o7J3 Hh4fGrjJmxTsq2O3E9/qg0yWSEzlCBhAXl/D+GTyUJA/KfIuCbdsuS5opprSrBZztqMYcGSCQJFz lE+esdbCXazdyEww5XfiGVgKiRyV2ycXyxNjekowbcDffSsOYplGBjJwPRYpESgfCYDXm+yyDQhy Xk0pxNEA7ob5fAMellN8FcgLfQtwSRcg8cYl/m8/BeVl6+eZuzCb061PdUN+mDf6erS55tXqgWJ3 toTp3GGaaOwwGs/bA1UnLqYm93RfTyL3kU1OWG8syPFMLoIwggfiMIIFyqADAgECAgEOMA0GCSqG SIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAyNTRaFw0xMjEwMjIyMTAyNTRaMIGM MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmlt YXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDLKIVFnAEs+xnyq6UzjCqgDcvQVe1dIoFnRsQPCFO+y92k8RK0Pn3MbQ2Gd+mehh9GBZ+36uUQ A7Xj9AGM6wgPhEE34vKtfpAN5tJ8LcFxveDObCKrL7O5UT9WsnAZHv7OYPYSR68mdmnEnJ83M4wQ gKO19b+Rt8sPDAz9ptkQsntCn4GeJzg3q2SVc4QJTg/WHo7wF2ah5LMOeh8xJVSKGEmd6uPkSbj1 13yKMm8vmNptRPmM1+YgmVwcdOYJOjCgFtb2sOP79jji8uhWR91xx7TpM1K3hv/wrBZwffrmmEpU euXHRs07JqCCvFh9coKF4UQZvfEg+x3/69xRCzb1AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/ MAsGA1UdDwQEAwIBpjAdBgNVHQ4EFgQUrlWDb+wxyrn3HfqvazHzyB3jrLswgagGA1UdIwSBoDCB nYAUTgvvGqRAW6UXaYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEp MCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9 BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYDVR0gBIIB VDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0 Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcv aW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQgQ29tbWVyY2lhbCAoU3Rh cnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpM ZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5 IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYw EQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIBDQRDFkFTdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVtYWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUF AAOCAgEAHvcQF/726YR5L5A3Ta7JV1nTu3w9yWqp00945pg7uea+1KVtR/7/yeNFAV7MPQylPE8p ROEcGU+RwwDFuNn9cePfAMzOBTpy/6VE076+gYkZa4n8uWaL5A2FVo8tRmEyfoT4gRL9B5h5w8Y4 ZySCJBLyfp4jByyxHaTTIWZ8TIkxUQLSBeFnmHKYFwYwMbBA0Sgb8ONCvq9zeJcpMkkDadhJSCfB 9c9gZocbaaVHVqTlSeENRr5/Y31dapzIRQg2Pl9V/A65Cq03KQxMXBpXn8HkLO/g2FCt7KYkJCaT e6qT2JX8thmB3nb+5RmtWQIITCP+PPNkFQCts6ujOtJx6TlDLWA+tV7QLN2Q+S98p/SwnXito+GW 0N7kXcL8QDBVsF8lCvwCz+JQrvUIcW5xEzpAVk9xSbpePxVIMzNEUQhBobkFojhUqGt+VyU3GH/+ BP2brzl4StOJ1KXuw2EzFs0ai9OMsqCUFRyhykm6MrbnsnSrqhWSnSQPYIu+zpzwWC/8sZFxoJCw vbbIu+6E+AIGa8tP+pYF+empPn/7pkIoTT4LSkkEIxGKvUvDJTh86VDNL8bIIQE2LHVDwcOq+mcQ x416FAA9Nw1DBGyrFr6hQe5yTVXrJ4G7vJosNRGCwPnx302gonaFdwi++YyqjPyhPO6q4fRarYvW yqp5L6UxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0 ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzAJBgUr DgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDA1 MjQxOTQzNjBaMCMGCSqGSIb3DQEJBDEWBBRzNINrEj31CId3bHnL+ABpXOIFPDCBpAYJKwYBBAGC NxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgZDMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzANBgkqhkiG9w0BAQEFAASC AQBNTF53nyZZUzX7yJKR1wzekuVDrlFPktf5JgZNjIF7HdRO6Fz2beRjpUlHZ7wK+UD8G17gdGeV wIAZaSNkLajMY6qxPImGY1A0rFsd+R7xYUxDLdbGG51VmvFyp0k8TlTkpibYhFst/aKKTFp16+os H9vHmxQedaD9sZQ8OC04TuWPZDYCJQ3C/5kZk8bZiCUue7NUfdK7hE/gFSoQkZOlEe2dVeqjTHW6 8cs/Lv+MrzRAIapmnB24KecaPTyqbHPLZIRSBZjRtnnJKm8/64ZIjo/4E/lTDK0B1tv6yrazhqeH dHwGXlpFjI4Bi63EQ91d1/hYgTthPoi1ZECqbgHwAAAAAAAA --Apple-Mail-104-70296524--
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]