[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xri] SimpleSign Implementation
On Wed, Dec 24, 2008 at 4:40 PM, Barnhill, William [USA] <barnhill_william@bah.com> wrote: > > SNI extension would be nice to use in spec, but I'm -1 because of the lack > of support in OpenSSL. Many languages, including Erlang, base their TLS > libraries on OpenSSL and SNI support is not baked in yet (possibly in > 0.9.9). If you made an SNI suage profile a separate optional extension > document, that could work as the devs using an OpenSSL with no SNI support > would not be impacted. > > "Originally no released version of OpenSSL supported SNI it was an > experimental addition to the HEAD which will become 0.9.9-dev." > - Dr Stephen N. Henson., Core OpenSSL dev, on the mod_ssl list > http://www.mail-archive.com/dev@httpd.apache.org/msg39034.html SNI went into OpenSSL 0.9.8f, over a year ago, I believe. > I found XML DSig complicated as well, but it seems well modularized so that > you could create a SimpleSign XML DSig profile that removed a lot of the > complexity. > > As for lack of implementations that seems to be changing, with > implementations in Java, C#, Visual Basic, and the more popular scripting > languages. See the following links for more info: > .. > http://identitymeme.org/archives/2006/12/20/xmldsig-implementations-for-scripting-languages/ > .. http://www.example-code.com/vb/sig.asp > .. http://www.cpan.org/modules/by-module/Net/zxid-0.19.readme > .. > http://www.koders.com/csharp/fid9399EBD1942CEF08BBA770E41302AB42B452B9B4.aspx > > YMMV on the above, but they do exist. > > Also, the SAML TC takes a different approach that presents another option: > "This specification defines a SAML HTTP protocol binding, specifically using > the HTTP POST method, and > which specifically does not use XML Digital Signature [XMLSig] for SAML > message data origination > authentication. Rather, a "sign the BLOB" technique is employed wherein a > conveyed SAML message, > along with any content (e.g. SAML assertion(s)), is treated as a simple > octet string if it is signed." > - SAMLv2.0 HTTP POST "SimpleSign" Binding CS01 > > http://www.oasis-open.org/committees/download.php/28046/sstc-saml-binding-simplesign-cs-01.pdf > > =Bill.Barnhill > > -----Original Message----- > From: Ben Laurie [mailto:benl@google.com] > Sent: Wed 12/24/2008 6:54 AM > To: Nat Sakimura > Cc: Joseph Anthony Pasquale Holsten; XRI TC > Subject: Re: [xri] SimpleSign Implementation > > On Wed, Dec 24, 2008 at 3:16 AM, Nat Sakimura <n-sakimura@nri.co.jp> wrote: >> >> >> Ben Laurie wrote: >>> >>> On Mon, Dec 22, 2008 at 1:29 AM, Nat Sakimura <n-sakimura@nri.co.jp> >>> wrote: >>> >>>> >>>> Hi. >>>> >>>> No, it si not silly. It is a good question to ask. >>>> >>>> My answer would be: >>>> >>>> a) TLS is only a security for the pipes. It does not protect the message >>>> per >>>> se. >>>> With a signed document, you can verify the authenticity and validity of >>>> a >>>> cache / detached document. >>>> b) TLS requires a dedicated IP address. Sites like Google providing >>>> services >>>> to >>>> the companies in the companies' domain do not have enough IP address to >>>> server TLS. >>>> This is another reason. >>>> >>> >>> This is not actually true anymore - you can use the SNI extension to >>> share an IP address. Because legacy browsers don't support it, it >>> isn't so great for websites, but for a specialist application like >>> retrieving XRD it would work just fine. >>> >> >> Are they implemented widely in common scripting language libraries? > > Yes. > >> Are they implemented widely in the current http servers? > > Yes. > >>> >>> >>>> >>>> c) There are not enough XMLDSIG implementations yet, and it is complex >>>> to >>>> implement yourself. >>>> This is becoming a hinderance to the adoption. >>>> >>>> a) and b) calls for a message based protection. This calls for something >>>> like XML Dsig. >>>> c) Calls for something simpler than XML Dsig. >>>> >>> >>> Or more implementations. >>> >> >> Yes. And we are not seeing these yet, unfortunately. >> (BTW, that's another initiative I am willing to run when I get more >> bandwidth.) >>> >>> >>>> >>>> Therefore, we have SimpleSign. >>>> >>>> Regards, >>>> >>>> =nat >>>> >>>> Joseph Anthony Pasquale Holsten wrote: >>>> >>>>> >>>>> I'm trying to wrap my head around the security implications of >>>>> SimpleSign, and I'm wondering where exactly it is better than TLS or >>>>> XMLDSIG. >>>>> >>>>> While SimpleSign is designed to be easy to implement, it still has >>>>> less implementations than TLS, or even XMLDSIG. There is also less >>>>> existing security analysis, test cases, &c. >>>>> >>>>> The certificate from SimpleSign is X509, so depends upon the support >>>>> of a CA. A certificate will only be valid if the subject applies to >>>>> the CannonicalID. Getting such a certificate will cost the same as a >>>>> TLS certificate, if they are not the identical. >>>>> >>>>> Why should I use a SimpleSign implementation instead of TLS or XMLDSIG? >>>>> >>>>> Some possible answers: >>>>> * You shouldn't. (NO!!!) >>>>> * Using TLS would require either all resources must be encrypted and >>>>> sign (significant overhead), or that the XRD must be available under >>>>> TLS while other resources may not (significant complexity). >>>>> * Using TLS means that an XRD cannot be provided under restrictive >>>>> hosting environments, as it cannot be implemented by uploading a PHP >>>>> script over FTP. >>>>> * Using XMLDSIG requires either a custom implementation (error >>>>> prone), or support for a known-good implementation (restricted >>>>> environments). >>>>> * SimpleSign is simple enough that an amateur can implement it >>>>> without worry of error, is easy to host, and allows flexible security >>>>> for other resources. >>>>> >>>>> http://josephholsten.com >>>>> >>>>> PS. I'm still trying to get up to speed with everything in XRI, so >>>>> I'm sorry if I ask silly questions >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe from this mail list, you must leave the OASIS TC that >>>>> generates this mail. Follow this link to all your TCs in OASIS at: >>>>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >>>>> >>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe from this mail list, you must leave the OASIS TC that >>>> generates this mail. Follow this link to all your TCs in OASIS at: >>>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >>>> >>>> >> > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]