Re: [OpenID] Signing method for XRD

[David Garcia]

Hi Nat,

yes you're right most of those impls are wrappers over aleksey's xmlsec
library.
Using wrappers requires systems running those services to have xmlsec lib
installed.

Most unix like distros are shipped with this xmlsec and if not it could be
downloaded from the aleksey site (
http://www.aleksey.com/xmlsec/download/xmlsec1-1.2.9.tar.gz).

Processing on xmlsignature is not very complex, but transforms like c14n
are.

So most complex processes are to perform those transformation processes that
are complicated to implement and very aggressive on computation
requirements.

As I said yesterday this morning I made a comparative of some available
options and what I've liked most is http://xmlsig.sourceforge.net/

This lib provides a set of wrappers over xmlsec made available using swig.
Those bindings that are suposed to work in php, python and ruby. I tested
the ruby version.

Installation requires libxml, libsxlt, swig and libxmlsec including their
-dev packages. I have to fix some include paths on building because make
didn't find header files from those libs.

I started the process from the scratch and took me less than 1 hour to have
ruby code performing enveloped/enveloping signature creation and validation
(only crypto validation no certificate validation process is included).

I submit the code I created to have a message signer/validator. The examples
available on the test directory from the lib are awesome to know how to
perform signing and verification primitives calls.

So my point of view about using pure dynamic libs or libs creating a bridge
over C libs is depend. Pure dynamic libs are easier to deploy but in some
cases like openssl, xml processing or in this case xml signature (core
tasks) bridging could be a good alternative.

I post here my sample code on ruby. I got it working on Ubuntu running on
amd64 and debian running on power g4 but the doc claims the lib working on
most UNIX like systems including MacOSX and Windows.

Hope this helps :)

Best regards

Dave

require 'xmlsig'
class MessageSigner

def self.sign_message(message , xpath = nil)
x = Xmlsig::XmlDoc.new
x.loadFromString(message)

private_key = Xmlsig::Key.new
private_key.loadFromFile('rsakey.pem','pem','')

signing_certificate = Xmlsig::Signer.new(x,private_key)
signing_certificate.addCertFromFile('rsacert.pem', 'pem')

if (xpath.nil?)
signed_signature = signing_certificate.sign
return signed_signature.toString
else
xp = Xmlsig::XPath.new
xp.setXPath(xpath)
signing_certificate.signInPlace(xp)
return x.toString
end
end

def self.verify_message(signed_message)
to_be_verified = Xmlsig::XmlDoc.new
to_be_verified.loadFromString(signed_message)

#Assuming a single signature per message
xp = Xmlsig::XPath.new()
xp.addNamespace('ds', 'http://www.w3.org/2000/09/xmldsig#')
xp.setXPath('/descendant::ds:Signature[position()=1]')
v = Xmlsig::Verifier.new(to_be_verified,xp)
valid = v.verify

return valid == 1
end

message = "message content "


#Second param is xpath.
#If not provided signature will be enveloping, this is signed message will
be embeded inside ds:Object node
#Providing Xpath will result in the signature being embeded inside the
message to be signed, that is an enveloped signature
signed_message = sign_message(message, "/Message")


valid = verify_message(signed_message)

puts "Signature #{valid ? "is" : "isn't"} valid!"

#Trying to cheat the signature validator
signed_message = signed_message.gsub(/content/, "other content")
valid = verify_message(signed_message)

puts "Signature #{valid ? "is" : "isn't"} valid!"

end

2009/6/13 Nat Sakimura 

> Thanks David,
> One of the issue that has been raised was that much of those scripting
> languages implementation actually calls C++ library to do the task. This
> makes it difficult to deploy it in some hosting and PaaS environment, so
> libs written in that scripting language is sought.
>
> If it is not there, then we need to evaluate how easy is it to do that, and
> perhaps create a project to make them.
>
> Cheers,
>
> =nat
>
>
> On Sat, Jun 13, 2009 at 3:01 AM, David Garcia  wrote:
>
>> Hi,
>>
>> Sure I'll do it, but let me make an in-depth analisis of alternatives
>> before pointing to a concrete implementation.
>>
>> I'll rebrowse sources to make those checks this weekend.
>>
>> Best regards
>>
>> David Garcia
>>
>> El 12/06/2009, a las 19:19, Tatsuki Sakushima  escribió:
>>
>>
>>  Hi David,
>>>
>>>  I completely agree with you, a single technology for those closely
 related protocols would be better than forking. The main advantage using
 XMLdSIG is that there are a huge amount of services currently working with
 this technology. As far as I know there are mature libs for C, C++, Java,
 .net, python, ruby, php .

>>>
>>> Can you navigate us to some libraries you have seen especially for those
>>> scripting languages, python, ruby,

Re: [OpenID] Signing method for XRD

[Nat Sakimura]

Thanks David,
One of the issue that has been raised was that much of those scripting
languages implementation actually calls C++ library to do the task. This
makes it difficult to deploy it in some hosting and PaaS environment, so
libs written in that scripting language is sought.

If it is not there, then we need to evaluate how easy is it to do that, and
perhaps create a project to make them.

Cheers,

=nat

On Sat, Jun 13, 2009 at 3:01 AM, David Garcia  wrote:

> Hi,
>
> Sure I'll do it, but let me make an in-depth analisis of alternatives
> before pointing to a concrete implementation.
>
> I'll rebrowse sources to make those checks this weekend.
>
> Best regards
>
> David Garcia
>
> El 12/06/2009, a las 19:19, Tatsuki Sakushima  escribió:
>
>
>  Hi David,
>>
>>  I completely agree with you, a single technology for those closely
>>> related protocols would be better than forking. The main advantage using
>>> XMLdSIG is that there are a huge amount of services currently working with
>>> this technology. As far as I know there are mature libs for C, C++, Java,
>>> .net, python, ruby, php .
>>>
>>
>> Can you navigate us to some libraries you have seen especially for those
>> scripting languages, python, ruby, and php? So some of us including me can
>> test them and see how they works. Some forks expertizing XML says XML DSig
>> with exclusive c14n is "easy enough", but many of us haven't seen the real
>> example in scripting languages. And if it is easy or not is somewhat
>> subjective. I think showing examples will facilitate this discussion.
>>
>> Best,
>> Tatsuki
>>
>> Tatsuki Sakushima
>> NRI Pacific - Nomura Research Institute America, Inc.
>>
>> (6/12/09 1:48 AM), David Garcia wrote:
>>
>>> Hi Nat,
>>> I completely agree with you, a single technology for those closely
>>> related protocols would be better than forking. The main advantage using
>>> XMLdSIG is that there are a huge amount of services currently working with
>>> this technology. As far as I know there are mature libs for C, C++, Java,
>>> .net, python, ruby, php .
>>> Those libs are compliant with xmldsig interopt tests so this give us
>>> warranties about their intertoperability. Message sign and verify primitives
>>> are very simple from the point of view of the developer and the only problem
>>> arises when trying to verify the signer certificate (path building,
>>> validation, status validation vs CRL and OCSP...) but several "tricks" could
>>> be made here to keep the process simple.
>>> I'll feel very comfortable about using XMLdSIG because from the point of
>>> view of the increase of complexity it won't be as easy as raw data
>>> processing, but it won't be very painful if we use those sets of libs.
>>> If you want maybe we can create a little project for a proof of concept
>>> and make an interop between 2 different technologies signing and verifying
>>> messages. If so please let me know :).
>>> Best regards
>>> Dave
>>> 2009/6/12 =nat mailto:sakim...@gmail.com>>
>>>   Hi.
>>>   Thanks for your great feedback.
>>>   It is kind of interesting that OpenID side wants the simplest form
>>> while
>>>   in the OAuth list, XML DSig is liked better somehow.
>>>>From the spec point of view, it is better to not to fork as much as
>>>   possible,
>>>   so if we can stick to XML DSig, that's great.
>>>   Now, here is another question then.
>>>   If libraries with decent API becomes available to each language,
>>>   written in that language, and is tested for compatibility to each
>>> other,
>>>   would you be amiable to this constrained form of XML DSig?
>>>   =nat
>>>   On Thu, 11 Jun 2009 16:14:56 +0200, David Garcia
>>>   mailto:david.gar...@tractis.com>>
>>>   wrote:
>>>> Hi Hans,
>>>>
>>>> this project offers a set of wrappers over xmlsec library used on
>>>   many
>>>   c++
>>>> envs. I used it a lot and their equivalent in Java for some years on
>>>> critical production envs and they're very mature.
>>>>
>>>> Dealing with xml data as opaque bits (a simplified xml version of
>>> CMS
>>>> signature containers) instead of interpreting the infoset as
>>> proposed
>>>   will
>>>> be a much simpler approach because it eliminates the need of
>>>   using c14n
>>>> and
>>>> transform algorithms (not mandatory but recommended on some
>>>   scenarios).
>>>>
>>>> Maybe this simpler approach will fit for message exchange.
>>>>
>>>> Best regards
>>>>
>>>> Dave Garcia
>>>>
>>>>
>>>> 2009/6/11 Hans Granqvist >>   >
>>>>
>>>>> Perhaps someone from VeriSign (Barry? Gary?) can comment on the
>>>> viability
>>>>> of
>>>>> http://xmlsig.sourceforge.net/
>>>>>
>>>>> Hans
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Jun 10, 2009 at 11:54 PM, John Panzer>>   > wrote:
>>>>> > My general impression is that something that requires two
>>>   pieces of
>>>>> software
>>>>> > to agree on

Re: [OpenID] Signing method for XRD

[Tatsuki Sakushima]

Hi David,

I completely agree with you, a single technology for those closely 
related protocols would be better than forking. The main advantage using 
XMLdSIG is that there are a huge amount of services currently working 
with this technology. As far as I know there are mature libs for C, C++, 
Java, .net, python, ruby, php .


Can you navigate us to some libraries you have seen especially for those scripting 
languages, python, ruby, and php? So some of us including me can test them and see how 
they works. Some forks expertizing XML says XML DSig with exclusive c14n is "easy 
enough", but many of us haven't seen the real example in scripting languages. And if 
it is easy or not is somewhat subjective. I think showing examples will facilitate this 
discussion.

Best,
Tatsuki

Tatsuki Sakushima
NRI Pacific - Nomura Research Institute America, Inc.

(6/12/09 1:48 AM), David Garcia wrote:

Hi Nat,

I completely agree with you, a single technology for those closely 
related protocols would be better than forking. The main advantage using 
XMLdSIG is that there are a huge amount of services currently working 
with this technology. As far as I know there are mature libs for C, C++, 
Java, .net, python, ruby, php .


Those libs are compliant with xmldsig interopt tests so this give us 
warranties about their intertoperability. Message sign and verify 
primitives are very simple from the point of view of the developer and 
the only problem arises when trying to verify the signer certificate 
(path building, validation, status validation vs CRL and OCSP...) but 
several "tricks" could be made here to keep the process simple.


I'll feel very comfortable about using XMLdSIG because from the point of 
view of the increase of complexity it won't be as easy as raw data 
processing, but it won't be very painful if we use those sets of libs.


If you want maybe we can create a little project for a proof of concept 
and make an interop between 2 different technologies signing and 
verifying messages. If so please let me know :).


Best regards

Dave

2009/6/12 =nat mailto:sakim...@gmail.com>>


Hi.

Thanks for your great feedback.

It is kind of interesting that OpenID side wants the simplest form while
in the OAuth list, XML DSig is liked better somehow.

 >From the spec point of view, it is better to not to fork as much as
possible,
so if we can stick to XML DSig, that's great.

Now, here is another question then.

If libraries with decent API becomes available to each language,
written in that language, and is tested for compatibility to each other,
would you be amiable to this constrained form of XML DSig?

=nat

On Thu, 11 Jun 2009 16:14:56 +0200, David Garcia
mailto:david.gar...@tractis.com>>
wrote:
 > Hi Hans,
 >
 > this project offers a set of wrappers over xmlsec library used on
many
c++
 > envs. I used it a lot and their equivalent in Java for some years on
 > critical production envs and they're very mature.
 >
 > Dealing with xml data as opaque bits (a simplified xml version of CMS
 > signature containers) instead of interpreting the infoset as proposed
will
 > be a much simpler approach because it eliminates the need of
using c14n
 > and
 > transform algorithms (not mandatory but recommended on some
scenarios).
 >
 > Maybe this simpler approach will fit for message exchange.
 >
 > Best regards
 >
 > Dave Garcia
 >
 >
 > 2009/6/11 Hans Granqvist mailto:h...@granqvist.com>>
 >
 >> Perhaps someone from VeriSign (Barry? Gary?) can comment on the
 > viability
 >> of
 >> http://xmlsig.sourceforge.net/
 >>
 >> Hans
 >>
 >>
 >>
 >> On Wed, Jun 10, 2009 at 11:54 PM, John Panzermailto:jpan...@acm.org>> wrote:
 >> > My general impression is that something that requires two
pieces of
 >> software
 >> > to agree on an exact, bit for bit infoset representation of an XML
 >> document
 >> > in order to get security to work is a poor idea.  I have seen
no wide
 >> > deployments/usage of DSig in Atom feeds -- despite it being
part of
 > the
 >> spec
 >> > -- and many complaints about how it's not possible to get it
to work
 >> > reliably given the software stacks currently in use.  The
difficulties
 >> with
 >> > canonicalization-for-signing in OAuth implementations have also
 >> reinforced
 >> > my belief that it's much better to err on the side of the
robust and
 >> simple.
 >> >
 >> > Signing a stream of uninterpreted bytes cuts out a whole slew of
 > failure
 >> > modes, and the ones that remain are debuggable -- the bytes
match or
 > they
 >> > don't, and standard tools can tell you which.  It means it's
possible
 > to
 >> > verify a signature with curl + a command line utility.  These
are al

Re: [OpenID] Signing method for XRD

[David Garcia]

Hi Nat,

I completely agree with you, a single technology for those closely related
protocols would be better than forking. The main advantage using XMLdSIG is
that there are a huge amount of services currently working with this
technology. As far as I know there are mature libs for C, C++, Java, .net,
python, ruby, php .

Those libs are compliant with xmldsig interopt tests so this give us
warranties about their intertoperability. Message sign and verify primitives
are very simple from the point of view of the developer and the only problem
arises when trying to verify the signer certificate (path building,
validation, status validation vs CRL and OCSP...) but several "tricks" could
be made here to keep the process simple.

I'll feel very comfortable about using XMLdSIG because from the point of
view of the increase of complexity it won't be as easy as raw data
processing, but it won't be very painful if we use those sets of libs.

If you want maybe we can create a little project for a proof of concept and
make an interop between 2 different technologies signing and verifying
messages. If so please let me know :).

Best regards

Dave

2009/6/12 =nat 

>
> Hi.
>
> Thanks for your great feedback.
>
> It is kind of interesting that OpenID side wants the simplest form while
> in the OAuth list, XML DSig is liked better somehow.
>
> From the spec point of view, it is better to not to fork as much as
> possible,
> so if we can stick to XML DSig, that's great.
>
> Now, here is another question then.
>
> If libraries with decent API becomes available to each language,
> written in that language, and is tested for compatibility to each other,
> would you be amiable to this constrained form of XML DSig?
>
> =nat
>
> On Thu, 11 Jun 2009 16:14:56 +0200, David Garcia  >
> wrote:
> > Hi Hans,
> >
> > this project offers a set of wrappers over xmlsec library used on many
> c++
> > envs. I used it a lot and their equivalent in Java for some years on
> > critical production envs and they're very mature.
> >
> > Dealing with xml data as opaque bits (a simplified xml version of CMS
> > signature containers) instead of interpreting the infoset as proposed
> will
> > be a much simpler approach because it eliminates the need of using c14n
> > and
> > transform algorithms (not mandatory but recommended on some scenarios).
> >
> > Maybe this simpler approach will fit for message exchange.
> >
> > Best regards
> >
> > Dave Garcia
> >
> >
> > 2009/6/11 Hans Granqvist 
> >
> >> Perhaps someone from VeriSign (Barry? Gary?) can comment on the
> > viability
> >> of
> >> http://xmlsig.sourceforge.net/
> >>
> >> Hans
> >>
> >>
> >>
> >> On Wed, Jun 10, 2009 at 11:54 PM, John Panzer wrote:
> >> > My general impression is that something that requires two pieces of
> >> software
> >> > to agree on an exact, bit for bit infoset representation of an XML
> >> document
> >> > in order to get security to work is a poor idea.  I have seen no wide
> >> > deployments/usage of DSig in Atom feeds -- despite it being part of
> > the
> >> spec
> >> > -- and many complaints about how it's not possible to get it to work
> >> > reliably given the software stacks currently in use.  The difficulties
> >> with
> >> > canonicalization-for-signing in OAuth implementations have also
> >> reinforced
> >> > my belief that it's much better to err on the side of the robust and
> >> simple.
> >> >
> >> > Signing a stream of uninterpreted bytes cuts out a whole slew of
> > failure
> >> > modes, and the ones that remain are debuggable -- the bytes match or
> > they
> >> > don't, and standard tools can tell you which.  It means it's possible
> > to
> >> > verify a signature with curl + a command line utility.  These are all
> >> very
> >> > good things.
> >> >
> >> > (As a side note, it would also make the content type orthogonal to the
> >> > signature code -- this is a good thing.)
> >> >
> >> > So, +1 for the simplest form of signing that could possibly work.
> >> >
> >> > -John
> >> >
> >> >
> >> > Johannes Ernst wrote:
> >> >
> >> > I proposed something I called XML-RSig for similar reasons a few years
> >> ago:
> >> >
> >> http://netmesh.info/jernst/Technical/really-simple-xml-signatures.html
> >> >
> >> > "RSig" for "Really simple Signature".
> >> >
> >> > The trouble for OpenID and XRD and so forth is that it is not our core
> >> > competency -- and shouldn't be -- to innovate around things that
> > really
> >> > aren't our business. Signing XML documents isn't our business.
> >> >
> >> > On the other hand, the people whose business it should be somehow seem
> > to
> >> be
> >> > asleep at the wheel, as the problems are well-known and somehow aren't
> >> being
> >> > addressed, and haven't for years.
> >> >
> >> > It seems to me that the best way out of this conundrum is:
> >> > 1. to foresee, architecturally, the use of several different ways of
> >> > constructing signatures, as the matter clearly isn't settled
> >> > 2. to make sure that high-end approaches

Re: [OpenID] Signing method for XRD

[=nat]

Hi. 

Thanks for your great feedback. 

It is kind of interesting that OpenID side wants the simplest form while 
in the OAuth list, XML DSig is liked better somehow. 

>From the spec point of view, it is better to not to fork as much as
possible, 
so if we can stick to XML DSig, that's great. 

Now, here is another question then. 

If libraries with decent API becomes available to each language, 
written in that language, and is tested for compatibility to each other, 
would you be amiable to this constrained form of XML DSig? 

=nat

On Thu, 11 Jun 2009 16:14:56 +0200, David Garcia 
wrote:
> Hi Hans,
> 
> this project offers a set of wrappers over xmlsec library used on many
c++
> envs. I used it a lot and their equivalent in Java for some years on
> critical production envs and they're very mature.
> 
> Dealing with xml data as opaque bits (a simplified xml version of CMS
> signature containers) instead of interpreting the infoset as proposed
will
> be a much simpler approach because it eliminates the need of using c14n
> and
> transform algorithms (not mandatory but recommended on some scenarios).
> 
> Maybe this simpler approach will fit for message exchange.
> 
> Best regards
> 
> Dave Garcia
> 
> 
> 2009/6/11 Hans Granqvist 
> 
>> Perhaps someone from VeriSign (Barry? Gary?) can comment on the
> viability
>> of
>> http://xmlsig.sourceforge.net/
>>
>> Hans
>>
>>
>>
>> On Wed, Jun 10, 2009 at 11:54 PM, John Panzer wrote:
>> > My general impression is that something that requires two pieces of
>> software
>> > to agree on an exact, bit for bit infoset representation of an XML
>> document
>> > in order to get security to work is a poor idea.  I have seen no wide
>> > deployments/usage of DSig in Atom feeds -- despite it being part of
> the
>> spec
>> > -- and many complaints about how it's not possible to get it to work
>> > reliably given the software stacks currently in use.  The difficulties
>> with
>> > canonicalization-for-signing in OAuth implementations have also
>> reinforced
>> > my belief that it's much better to err on the side of the robust and
>> simple.
>> >
>> > Signing a stream of uninterpreted bytes cuts out a whole slew of
> failure
>> > modes, and the ones that remain are debuggable -- the bytes match or
> they
>> > don't, and standard tools can tell you which.  It means it's possible
> to
>> > verify a signature with curl + a command line utility.  These are all
>> very
>> > good things.
>> >
>> > (As a side note, it would also make the content type orthogonal to the
>> > signature code -- this is a good thing.)
>> >
>> > So, +1 for the simplest form of signing that could possibly work.
>> >
>> > -John
>> >
>> >
>> > Johannes Ernst wrote:
>> >
>> > I proposed something I called XML-RSig for similar reasons a few years
>> ago:
>> >
>> http://netmesh.info/jernst/Technical/really-simple-xml-signatures.html
>> >
>> > "RSig" for "Really simple Signature".
>> >
>> > The trouble for OpenID and XRD and so forth is that it is not our core
>> > competency -- and shouldn't be -- to innovate around things that
> really
>> > aren't our business. Signing XML documents isn't our business.
>> >
>> > On the other hand, the people whose business it should be somehow seem
> to
>> be
>> > asleep at the wheel, as the problems are well-known and somehow aren't
>> being
>> > addressed, and haven't for years.
>> >
>> > It seems to me that the best way out of this conundrum is:
>> > 1. to foresee, architecturally, the use of several different ways of
>> > constructing signatures, as the matter clearly isn't settled
>> > 2. to make sure that high-end approaches (like XML-DSIG) work well,
> but
>> > low-end approaches (like XML-RSIG) work just as well
>> > 3. to maintain a best practices document that says "today, choice X is
>> your
>> > best bet, and we say that because based on our market research, X has
> the
>> > highest market share in terms of implementors today."
>> >
>> > As we all know, any problem in computer science can be solved by
> adding a
>> > level of indirection. This may well be one of those cases.
>> >
>> >
>> >
>> >
>> >
>> > Johannes Ernst
>> > NetMesh Inc.
>> >
>> >
>> > 
>> >
>> >
>> >
>> > 
>> >
>> >  http://netmesh.info/jernst
>> >
>> >
>> >
>> > 
>> > ___
>> > specs mailing list
>> > specs@openid.net
>> > http://openid.net/mailman/listinfo/specs
>> >
>> >
>> > ___
>> > specs mailing list
>> > specs@openid.net
>> > http://openid.net/mailman/listinfo/specs
>> >
>> >
>> ___
>> specs mailing list
>> specs@openid.net
>> http://openid.net/mailman/listinfo/specs
>>
> 
> 
> 
> --
> David Garcia
> CTO
> 
> Tractis - Online contracts you can enforce
> http://www.tractis.com
> --
> Tel: (34) 93 551 96 60 (ext. 260)
> 
> Email: david.gar...@tractis.com
> Blog: http://bl

Re: [OpenID] Signing method for XRD

[Allen Tom]

+1


John Panzer wrote:


So, +1 for the simplest form of signing that could possibly work.



___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: [OpenID] Signing method for XRD

[David Garcia]

Hi Hans,

this project offers a set of wrappers over xmlsec library used on many c++
envs. I used it a lot and their equivalent in Java for some years on
critical production envs and they're very mature.

Dealing with xml data as opaque bits (a simplified xml version of CMS
signature containers) instead of interpreting the infoset as proposed will
be a much simpler approach because it eliminates the need of using c14n and
transform algorithms (not mandatory but recommended on some scenarios).

Maybe this simpler approach will fit for message exchange.

Best regards

Dave Garcia


2009/6/11 Hans Granqvist 

> Perhaps someone from VeriSign (Barry? Gary?) can comment on the viability
> of
> http://xmlsig.sourceforge.net/
>
> Hans
>
>
>
> On Wed, Jun 10, 2009 at 11:54 PM, John Panzer wrote:
> > My general impression is that something that requires two pieces of
> software
> > to agree on an exact, bit for bit infoset representation of an XML
> document
> > in order to get security to work is a poor idea.  I have seen no wide
> > deployments/usage of DSig in Atom feeds -- despite it being part of the
> spec
> > -- and many complaints about how it's not possible to get it to work
> > reliably given the software stacks currently in use.  The difficulties
> with
> > canonicalization-for-signing in OAuth implementations have also
> reinforced
> > my belief that it's much better to err on the side of the robust and
> simple.
> >
> > Signing a stream of uninterpreted bytes cuts out a whole slew of failure
> > modes, and the ones that remain are debuggable -- the bytes match or they
> > don't, and standard tools can tell you which.  It means it's possible to
> > verify a signature with curl + a command line utility.  These are all
> very
> > good things.
> >
> > (As a side note, it would also make the content type orthogonal to the
> > signature code -- this is a good thing.)
> >
> > So, +1 for the simplest form of signing that could possibly work.
> >
> > -John
> >
> >
> > Johannes Ernst wrote:
> >
> > I proposed something I called XML-RSig for similar reasons a few years
> ago:
> >
> http://netmesh.info/jernst/Technical/really-simple-xml-signatures.html
> >
> > "RSig" for "Really simple Signature".
> >
> > The trouble for OpenID and XRD and so forth is that it is not our core
> > competency -- and shouldn't be -- to innovate around things that really
> > aren't our business. Signing XML documents isn't our business.
> >
> > On the other hand, the people whose business it should be somehow seem to
> be
> > asleep at the wheel, as the problems are well-known and somehow aren't
> being
> > addressed, and haven't for years.
> >
> > It seems to me that the best way out of this conundrum is:
> > 1. to foresee, architecturally, the use of several different ways of
> > constructing signatures, as the matter clearly isn't settled
> > 2. to make sure that high-end approaches (like XML-DSIG) work well, but
> > low-end approaches (like XML-RSIG) work just as well
> > 3. to maintain a best practices document that says "today, choice X is
> your
> > best bet, and we say that because based on our market research, X has the
> > highest market share in terms of implementors today."
> >
> > As we all know, any problem in computer science can be solved by adding a
> > level of indirection. This may well be one of those cases.
> >
> >
> >
> >
> >
> > Johannes Ernst
> > NetMesh Inc.
> >
> >
> > 
> >
> >
> >
> > 
> >
> >  http://netmesh.info/jernst
> >
> >
> >
> > 
> > ___
> > specs mailing list
> > specs@openid.net
> > http://openid.net/mailman/listinfo/specs
> >
> >
> > ___
> > specs mailing list
> > specs@openid.net
> > http://openid.net/mailman/listinfo/specs
> >
> >
> ___
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/specs
>



-- 
David Garcia
CTO

Tractis - Online contracts you can enforce
http://www.tractis.com
--
Tel: (34) 93 551 96 60 (ext. 260)

Email: david.gar...@tractis.com
Blog: http://blog.negonation.com
Twitter: http://twitter.com/tractis
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: [OpenID] Signing method for XRD

[Hans Granqvist]

Perhaps someone from VeriSign (Barry? Gary?) can comment on the viability of
http://xmlsig.sourceforge.net/

Hans



On Wed, Jun 10, 2009 at 11:54 PM, John Panzer wrote:
> My general impression is that something that requires two pieces of software
> to agree on an exact, bit for bit infoset representation of an XML document
> in order to get security to work is a poor idea.  I have seen no wide
> deployments/usage of DSig in Atom feeds -- despite it being part of the spec
> -- and many complaints about how it's not possible to get it to work
> reliably given the software stacks currently in use.  The difficulties with
> canonicalization-for-signing in OAuth implementations have also reinforced
> my belief that it's much better to err on the side of the robust and simple.
>
> Signing a stream of uninterpreted bytes cuts out a whole slew of failure
> modes, and the ones that remain are debuggable -- the bytes match or they
> don't, and standard tools can tell you which.  It means it's possible to
> verify a signature with curl + a command line utility.  These are all very
> good things.
>
> (As a side note, it would also make the content type orthogonal to the
> signature code -- this is a good thing.)
>
> So, +1 for the simplest form of signing that could possibly work.
>
> -John
>
>
> Johannes Ernst wrote:
>
> I proposed something I called XML-RSig for similar reasons a few years ago:
> http://netmesh.info/jernst/Technical/really-simple-xml-signatures.html
>
> "RSig" for "Really simple Signature".
>
> The trouble for OpenID and XRD and so forth is that it is not our core
> competency -- and shouldn't be -- to innovate around things that really
> aren't our business. Signing XML documents isn't our business.
>
> On the other hand, the people whose business it should be somehow seem to be
> asleep at the wheel, as the problems are well-known and somehow aren't being
> addressed, and haven't for years.
>
> It seems to me that the best way out of this conundrum is:
> 1. to foresee, architecturally, the use of several different ways of
> constructing signatures, as the matter clearly isn't settled
> 2. to make sure that high-end approaches (like XML-DSIG) work well, but
> low-end approaches (like XML-RSIG) work just as well
> 3. to maintain a best practices document that says "today, choice X is your
> best bet, and we say that because based on our market research, X has the
> highest market share in terms of implementors today."
>
> As we all know, any problem in computer science can be solved by adding a
> level of indirection. This may well be one of those cases.
>
>
>
>
>
> Johannes Ernst
> NetMesh Inc.
>
>
> 
>
>
>
> 
>
>  http://netmesh.info/jernst
>
>
>
> 
> ___
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/specs
>
>
> ___
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/specs
>
>
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: [OpenID] Signing method for XRD

[Nat Sakimura]

Hi John,
Thanks for your input!

=nat

On Thu, Jun 11, 2009 at 3:54 PM, John Panzer  wrote:

>  My general impression is that something that requires two pieces of
> software to agree on an exact, bit for bit infoset representation of an XML
> document in order to get security to work is a poor idea.  I have seen no
> wide deployments/usage of DSig in Atom feeds -- despite it being part of the
> spec -- and many complaints about how it's not possible to get it to work
> reliably given the software stacks currently in use.  The difficulties with
> canonicalization-for-signing in OAuth implementations have also reinforced
> my belief that it's much better to err on the side of the robust and simple.
>
> Signing a stream of uninterpreted bytes cuts out a whole slew of failure
> modes, and the ones that remain are debuggable -- the bytes match or they
> don't, and standard tools can tell you which.  It means it's possible to
> verify a signature with curl + a command line utility.  These are all very
> good things.
>
> (As a side note, it would also make the content type orthogonal to the
> signature code -- this is a good thing.)
>
> So, +1 for the simplest form of signing that could possibly work.
>
> -John
>
>
> Johannes Ernst wrote:
>
> I proposed something I called XML-RSig for similar reasons a few years ago:
>
> http://netmesh.info/jernst/Technical/really-simple-xml-signatures.html
>
> "RSig" for "Really simple Signature".
>
> The trouble for OpenID and XRD and so forth is that it is not our core
> competency -- and shouldn't be -- to innovate around things that really
> aren't our business. Signing XML documents isn't our business.
>
> On the other hand, the people whose business it should be somehow seem to
> be asleep at the wheel, as the problems are well-known and somehow aren't
> being addressed, and haven't for years.
>
> It seems to me that the best way out of this conundrum is:
> 1. to foresee, architecturally, the use of several different ways of
> constructing signatures, as the matter clearly isn't settled
> 2. to make sure that high-end approaches (like XML-DSIG) work well, but
> low-end approaches (like XML-RSIG) work just as well
> 3. to maintain a best practices document that says "today, choice X is your
> best bet, and we say that because based on our market research, X has the
> highest market share in terms of implementors today."
>
> As we all know, any problem in computer science can be solved by adding a
> level of indirection. This may well be one of those cases.
>
>
>
>
>
> Johannes Ernst
> NetMesh Inc.
>
>
> --
>
>
>
>  --
>
>   http://netmesh.info/jernst
>
>
>
>  --
> ___
> specs mailing listsp...@openid.nethttp://openid.net/mailman/listinfo/specs
>
>
>


-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: [OpenID] Signing method for XRD

[Nat Sakimura]

Hi Allen,

Thanks for your input.

What do you think of the proposal on
http://wiki.oasis-open.org/xri/XrdOne/SimpleSign ?
Would it be simple enough? (Well, I do not think it can go any simpler than
that but... ;-).
Would you implement it?

On Thu, Jun 11, 2009 at 1:52 PM, Allen Tom  wrote:

>  Hi Nat,
>
> Generating signatures is tricky, and XMLDSig is trickier than most. That
> being said, there are libraries that do it, and they do seem to work.
>
> First of all, I'd be happier to see something other than XML, but if XML
> has already been decided on, then I would not mind seeing something other
> than XMLDSig, if the alternative is significantly for developers to generate
> than XMLDSig.
>
> Allen
>
> Nat Sakimura wrote:
>
> Hmmm.
>
> Perhaps I did not spell my intent in the original mail well enough.
>
> My question was:
>
> (1) Is XML DSig easy enough for you developers to use?
> (2) Is XML DSig supported in your environemnt?
>e.g., Google AppEngine, Force.com, your hosting environment, your
> own server, etc.
> (3) If either (1) or (2) is negative, are you aimiable to use a very simple
> alternative to it,
>or you do not bother signing XRD at all?
>
> Best,
>
> =nat
>
> On Thu, Jun 11, 2009 at 4:16 AM, Santosh Rajan wrote:
>
>>
>> I agree that in XML they are not equivalent. Yes but the signing process
>> itself is binary, it has nothing to do with text or its meaning.
>>
>>
>> Hans Granqvist wrote:
>> >
>> >> Once you digitally sign a document, though physically the document
>> >> remains
>> >> in tact and retains its content type, after the act of signing, it is
>> >> really
>> >> a frozen bunch of bits. And if you dont make that distinction you get
>> >> into
>> >> all sorts of tangles. And that was the mistake made by XMLDSig. In
>> other
>> >> words after signing the Content-Type should be binary, whatever you
>> want
>> >> to
>> >> call it. After verification it takes up its original Content-Type.
>> >
>> > In XML these two are equivalent:
>> >
>> >
>> >
>> >
>> >
>>  > A signing process needs to understand this, and that is what XML Dsig
>> > does.
>> > XML was not defined to be a wire format.
>> >
>> > Hans
>> > ___
>> > general mailing list
>> > gene...@openid.net
>> > http://openid.net/mailman/listinfo/general
>> >
>> >
>>
>>
>>  -
>>
>> Santosh Rajan
>> http://santrajan.blogspot.com http://santrajan.blogspot.com
>> --
>>  View this message in context:
>> http://www.nabble.com/Signing-method-for-XRD-tp23956678p23969137.html
>> Sent from the OpenID - General mailing list archive at Nabble.com.
>>
>> ___
>>  general mailing list
>> gene...@openid.net
>> http://openid.net/mailman/listinfo/general
>>
>
>
>
> --
> Nat Sakimura (=nat)
> http://www.sakimura.org/en/
>
> --
> ___
> general mailing 
> listgene...@openid.nethttp://openid.net/mailman/listinfo/general
>
>
>


-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: [OpenID] Signing method for XRD

[Nat Sakimura]

When we first started discussing the topic, we started off with something
quite similar (in fact a little more simpler) than RSig.
The flow of our discussion over the last 6 months were like this:

The trait was like this.

1. XRDS has been using SAML constrained version of XML DSig, but nobody
implemented it.
There has to be something wrong in specifying this signature method.
(Also, we know that SAML XML DSig created a lot of compatibility issues
in the field. )
2. We have studied the current XML DSig implementations for script
languages, and
found that in most case, we have to link the C libraries. This is no go
for many hosting
environment, so we decided to make a simple alternative "Simple Sign".
3. We came up with Simple Canonicalization + X.509(RSA-SHA) Signature
method,
which can be implemented widely in many scripting languages.
4. Even this Simple Canonicalization raised an issue of comaptibility, so
decided to do
no Canonicalization at all.
5. This seemed to require a detached signature, but it would not be able to
deal with
sequence of XRDs. (Detached Sig)
6. Thus, we created SignedXRD (SXRD) method so that it can be inline, which
is currently in
  http://wiki.oasis-open.org/xri/XrdOne/SimpleSign

http://www.w3.org/2000/09/xmldsig#rsa-sha1";
certuri="pem file location" data="BASE64 of the payload" />

7. When writing a spec for Detached Sig, it has been found that we are
rewriting a lot of what has been in XML Dsig. Thus, XML Dsig with no
canonicalization was explored.
8. Then, it was argued that SAML core ch.5 version of XML DSig is simple
enough and there are scripting language implementations as well, though they
need
the C Libraries to be linked.
9. We are back to the square ONE. (<= We are here.)

My main concern about XML DSig are as follows:

1. Perception:
   If developers think it is too much, it is not going to be deployed.
2. Performance:
   In Java 6, it is not an issue, but in the past, it seems it has been.
3. Support:
   There are linkable C libraries for script languages, but are they
deployed or
deployable? For example, I do not think that can be deployed on Google
AppEngine Python. (Or is it? Please let me know!)
4. If support is not there, is it easy to write your own?
5. What about the performance then?

etc.

My Concern about Simple Sign only is

1. It is new: do people implement it?

My Concern about supporting both are:

1. Is it going to be too much to ask library writers to support both XML
Dsig and Simple Sign?

As a "ever indecisive" person, I tend to opt for "Both" option, but what do
you guys think of it?

=nat

On Thu, Jun 11, 2009 at 2:01 PM, Johannes Ernst  wrote:

> I proposed something I called XML-RSig for similar reasons a few years ago:
>
> http://netmesh.info/jernst/Technical/really-simple-xml-signatures.html
>
> "RSig" for "Really simple Signature".
>
> The trouble for OpenID and XRD and so forth is that it is not our core
> competency -- and shouldn't be -- to innovate around things that really
> aren't our business. Signing XML documents isn't our business.
>
> On the other hand, the people whose business it should be somehow seem to
> be asleep at the wheel, as the problems are well-known and somehow aren't
> being addressed, and haven't for years.
>
> It seems to me that the best way out of this conundrum is:
> 1. to foresee, architecturally, the use of several different ways of
> constructing signatures, as the matter clearly isn't settled
> 2. to make sure that high-end approaches (like XML-DSIG) work well, but
> low-end approaches (like XML-RSIG) work just as well
> 3. to maintain a best practices document that says "today, choice X is your
> best bet, and we say that because based on our market research, X has the
> highest market share in terms of implementors today."
>
> As we all know, any problem in computer science can be solved by adding a
> level of indirection. This may well be one of those cases.
>
>
>
>
>
> Johannes Ernst
> NetMesh Inc.
>
>
>
>  http://netmesh.info/jernst
>
>
>
>
>


-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: [OpenID] Signing method for XRD

[John Panzer]

My general impression is that something that requires two pieces of
software to agree on an exact, bit for bit infoset representation of an
XML document in order to get security to work is a poor idea.  I have
seen no wide deployments/usage of DSig in Atom feeds -- despite it
being part of the spec -- and many complaints about how it's not
possible to get it to work reliably given the software stacks currently
in use.  The difficulties with canonicalization-for-signing in OAuth
implementations have also reinforced my belief that it's much better to
err on the side of the robust and simple.

Signing a stream of uninterpreted bytes cuts out a whole slew of
failure modes, and the ones that remain are debuggable -- the bytes
match or they don't, and standard tools can tell you which.  It means
it's possible to verify a signature with curl + a command line
utility.  These are all very good things.

(As a side note, it would also make the content type orthogonal to the
signature code -- this is a good thing.)

So, +1 for the simplest form of signing that could possibly work.

-John


Johannes Ernst wrote:
I proposed something I called XML-RSig for similar reasons
a few years ago:
  
http://netmesh.info/jernst/Technical/really-simple-xml-signatures.html
  
  
"RSig" for "Really simple Signature".
  
  
The trouble for OpenID and XRD and so forth is that it is not our core
competency -- and shouldn't be -- to innovate around things that really
aren't our business. Signing XML documents isn't our business.
  
  
On the other hand, the people whose business it should be somehow seem
to be asleep at the wheel, as the problems are well-known and somehow
aren't being addressed, and haven't for years.
  
  
It seems to me that the best way out of this conundrum is:
  
1. to foresee, architecturally, the use of several different ways of
constructing signatures, as the matter clearly isn't settled
  
2. to make sure that high-end approaches (like XML-DSIG) work well, but
low-end approaches (like XML-RSIG) work just as well
  
3. to maintain a best practices document that says "today, choice X is
your best bet, and we say that because based on our market research, X
has the highest market share in terms of implementors today."
  
  
As we all know, any problem in computer science can be solved by adding
a level of indirection. This may well be one of those cases.
  
  
  
  
  
  
Johannes Ernst
  
NetMesh Inc.
  
  
  
  
  
   
  
  
  
  
   http://netmesh.info/jernst
  
  
  
  
  
  

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
  




___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: [OpenID] Signing method for XRD

[Johannes Ernst]

I proposed something I called XML-RSig for similar reasons a few years  
ago:

http://netmesh.info/jernst/Technical/really-simple-xml-signatures.html

"RSig" for "Really simple Signature".

The trouble for OpenID and XRD and so forth is that it is not our core  
competency -- and shouldn't be -- to innovate around things that  
really aren't our business. Signing XML documents isn't our business.


On the other hand, the people whose business it should be somehow seem  
to be asleep at the wheel, as the problems are well-known and somehow  
aren't being addressed, and haven't for years.


It seems to me that the best way out of this conundrum is:
1. to foresee, architecturally, the use of several different ways of  
constructing signatures, as the matter clearly isn't settled
2. to make sure that high-end approaches (like XML-DSIG) work well,  
but low-end approaches (like XML-RSIG) work just as well
3. to maintain a best practices document that says "today, choice X is  
your best bet, and we say that because based on our market research, X  
has the highest market share in terms of implementors today."


As we all know, any problem in computer science can be solved by  
adding a level of indirection. This may well be one of those cases.






Johannes Ernst
NetMesh Inc.

<>
 <>
 http://netmesh.info/jernst



___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: [OpenID] Signing method for XRD

[Allen Tom]

Hi Nat,

Generating signatures is tricky, and XMLDSig is trickier than most. That 
being said, there are libraries that do it, and they do seem to work.


First of all, I'd be happier to see something other than XML, but if XML 
has already been decided on, then I would not mind seeing something 
other than XMLDSig, if the alternative is significantly for developers 
to generate than XMLDSig.


Allen

Nat Sakimura wrote:

Hmmm.

Perhaps I did not spell my intent in the original mail well enough.

My question was:

(1) Is XML DSig easy enough for you developers to use?
(2) Is XML DSig supported in your environemnt?
   e.g., Google AppEngine, Force.com, your hosting environment, 
your own server, etc.
(3) If either (1) or (2) is negative, are you aimiable to use a very 
simple alternative to it,

   or you do not bother signing XRD at all?

Best,

=nat

On Thu, Jun 11, 2009 at 4:16 AM, Santosh Rajan > wrote:



I agree that in XML they are not equivalent. Yes but the signing
process
itself is binary, it has nothing to do with text or its meaning.


Hans Granqvist wrote:
>
>> Once you digitally sign a document, though physically the document
>> remains
>> in tact and retains its content type, after the act of signing,
it is
>> really
>> a frozen bunch of bits. And if you dont make that distinction
you get
>> into
>> all sorts of tangles. And that was the mistake made by XMLDSig.
In other
>> words after signing the Content-Type should be binary, whatever
you want
>> to
>> call it. After verification it takes up its original Content-Type.
>
> In XML these two are equivalent:
>
>
>
>
>
> A signing process needs to understand this, and that is what XML
Dsig
> does.
> XML was not defined to be a wire format.
>
> Hans
> ___
> general mailing list
> gene...@openid.net 
> http://openid.net/mailman/listinfo/general
>
>


-

Santosh Rajan
http://santrajan.blogspot.com http://santrajan.blogspot.com
--
View this message in context:
http://www.nabble.com/Signing-method-for-XRD-tp23956678p23969137.html
Sent from the OpenID - General mailing list archive at Nabble.com.

___
general mailing list
gene...@openid.net 
http://openid.net/mailman/listinfo/general




--
Nat Sakimura (=nat)
http://www.sakimura.org/en/


___
general mailing list
gene...@openid.net
http://openid.net/mailman/listinfo/general
  


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs