OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [xri] SimpleSign Implementation


Title: RE: [xri] SimpleSign Implementation

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

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]