Re: [OpenID] Signing method for XRD

[Allen Tom-2]

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 <santrajan@...> 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
> general@...
> 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
general@...
http://openid.net/mailman/listinfo/general

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

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

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

[Johannes Ernst-6]

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@...
http://openid.net/mailman/listinfo/specs

[John Panzer-3]

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@...
http://openid.net/mailman/listinfo/specs
  

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

[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

    <XRD sig="signature" sigalg="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 <[e-mail]> 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@...
http://openid.net/mailman/listinfo/specs

[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 <atom@...> 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 <santrajan@...> 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
> general@...
> 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
general@...
http://openid.net/mailman/listinfo/general

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

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

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

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

[Nat Sakimura]

Hi John, 

Thanks for your input!

=nat

On Thu, Jun 11, 2009 at 3:54 PM, John Panzer <jpanzer@...> 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@...
http://openid.net/mailman/listinfo/specs
  

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

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

[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<jpanzer@...> 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@...
> http://openid.net/mailman/listinfo/specs
>
>
> _______________________________________________
> specs mailing list
> specs@...
> http://openid.net/mailman/listinfo/specs
>
>

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

[David Garcia-6]

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 <hans@...>

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<jpanzer@...> 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@...
> http://openid.net/mailman/listinfo/specs
>
>
> _______________________________________________
> specs mailing list
> specs@...
> http://openid.net/mailman/listinfo/specs
>
>
_______________________________________________
specs mailing list
specs@...
http://openid.net/mailman/listinfo/specs

--
David Garcia
CTO

Tractis - Online contracts you can enforce
http://www.tractis.com
--
Tel: [phone] (ext. 260)

Email: david.garcia@...
Blog: http://blog.negonation.com
Twitter: http://twitter.com/tractis

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

[Allen Tom-2]

+1


John Panzer wrote:
>
> So, +1 for the simplest form of signing that could possibly work.
>

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

[Nat Sakimura]

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 <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 <hans@...>
>
>> 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<jpanzer@...> 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@...
>> > http://openid.net/mailman/listinfo/specs
>> >
>> >
>> > _______________________________________________
>> > specs mailing list
>> > specs@...
>> > http://openid.net/mailman/listinfo/specs
>> >
>> >
>> _______________________________________________
>> specs mailing list
>> specs@...
>> http://openid.net/mailman/listinfo/specs
>>
>
>
>
> --
> David Garcia
> CTO
>
> Tractis - Online contracts you can enforce
> http://www.tractis.com
> --
> Tel: [phone] (ext. 260)
>
> Email: david.garcia@...
> Blog: http://blog.negonation.com
> Twitter: http://twitter.com/tractis

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

[David Garcia-6]

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 <sakimura@...>

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 <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 <hans@...>
>
>> 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<jpanzer@...> 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@...
>> > http://openid.net/mailman/listinfo/specs
>> >
>> >
>> > _______________________________________________
>> > specs mailing list
>> > specs@...
>> > http://openid.net/mailman/listinfo/specs
>> >
>> >
>> _______________________________________________
>> specs mailing list
>> specs@...
>> http://openid.net/mailman/listinfo/specs
>>
>
>
>
> --
> David Garcia
> CTO
>
> Tractis - Online contracts you can enforce
> http://www.tractis.com
> --
> Tel: [phone] (ext. 260)
>
> Email: david.garcia@...
> Blog: http://blog.negonation.com
> Twitter: http://twitter.com/tractis

--
David Garcia
CTO

Tractis - Online contracts you can enforce
http://www.tractis.com
--
Tel: [phone] (ext. 260)

Email: david.garcia@...
Blog: http://blog.negonation.com
Twitter: http://twitter.com/tractis

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

[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 <sakimura@... <mailto:sakimura@...>>
>
>
>     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
>     <david.garcia@... <mailto: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 <hans@...
>     <mailto:hans@...>>
>      >
>      >> 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<jpanzer@...
>     <mailto:jpanzer@...>> 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@... <mailto:specs@...>
>      >> > http://openid.net/mailman/listinfo/specs
>      >> >
>      >> >
>      >> > _______________________________________________
>      >> > specs mailing list
>      >> > specs@... <mailto:specs@...>
>      >> > http://openid.net/mailman/listinfo/specs
>      >> >
>      >> >
>      >> _______________________________________________
>      >> specs mailing list
>      >> specs@... <mailto:specs@...>
>      >> http://openid.net/mailman/listinfo/specs
>      >>
>      >
>      >
>      >
>      > --
>      > David Garcia
>      > CTO
>      >
>      > Tractis - Online contracts you can enforce
>      > http://www.tractis.com
>      > --
>      > Tel: [phone] (ext. 260)
>      >
>      > Email: david.garcia@... <mailto:david.garcia@...>
>      > Blog: http://blog.negonation.com
>      > Twitter: http://twitter.com/tractis
>
>
>
>
> --
> David Garcia
> CTO
>
> Tractis - Online contracts you can enforce
> http://www.tractis.com
> --
> Tel: [phone] (ext. 260)
>
> Email: david.garcia@... <mailto:david.garcia@...>
> Blog: http://blog.negonation.com
> Twitter: http://twitter.com/tractis
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> specs mailing list
> specs@...
> http://openid.net/mailman/listinfo/specs

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

[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 <davebcn@...> 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 <tatsuki@...> 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 <sakimura@... <mailto:sakimura@...>>
  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
  <david.garcia@... <mailto: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 <hans@...
  <mailto:hans@...>>
   >
   >> 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<jpanzer@...
  <mailto:jpanzer@...>> 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@... <mailto:specs@...>
   >> > http://openid.net/mailman/listinfo/specs
   >> >
   >> >
   >> > _______________________________________________
   >> > specs mailing list
   >> > specs@... <mailto:specs@...>
   >> > http://openid.net/mailman/listinfo/specs
   >> >
   >> >
   >> _______________________________________________
   >> specs mailing list
   >> specs@... <mailto:specs@...>
   >> http://openid.net/mailman/listinfo/specs
   >>
   >
   >
   >
   > --
   > David Garcia
   > CTO
   >
   > Tractis - Online contracts you can enforce
   > http://www.tractis.com
   > --
   > Tel: [phone] (ext. 260)
   >
   > Email: david.garcia@... <mailto:david.garcia@...>
   > Blog: http://blog.negonation.com
   > Twitter: http://twitter.com/tractis
--
David Garcia
CTO
Tractis - Online contracts you can enforce
http://www.tractis.com
--
Tel: [phone] (ext. 260)
Email: david.garcia@... <mailto:david.garcia@...>
Blog: http://blog.negonation.com
Twitter: http://twitter.com/tractis
------------------------------------------------------------------------
_______________________________________________
specs mailing list
specs@...
http://openid.net/mailman/listinfo/specs

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

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

[David Garcia-6]

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>message content </Message>"


#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 <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 <davebcn@...> 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 <tatsuki@...> 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 <sakimura@... <mailto:sakimura@...>>
  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
  <david.garcia@... <mailto: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 <hans@...
  <mailto:hans@...>>
   >
   >> 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<jpanzer@...
  <mailto:jpanzer@...>> 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@... <mailto:specs@...>
   >> > http://openid.net/mailman/listinfo/specs
   >> >
   >> >
   >> > _______________________________________________
   >> > specs mailing list
   >> > specs@... <mailto:specs@...>
   >> > http://openid.net/mailman/listinfo/specs
   >> >
   >> >
   >> _______________________________________________
   >> specs mailing list
   >> specs@... <mailto:specs@...>
   >> http://openid.net/mailman/listinfo/specs
   >>
   >
   >
   >
   > --
   > David Garcia
   > CTO
   >
   > Tractis - Online contracts you can enforce
   > http://www.tractis.com
   > --
   > Tel: [phone] (ext. 260)
   >
   > Email: david.garcia@... <mailto:david.garcia@...>
   > Blog: http://blog.negonation.com
   > Twitter: http://twitter.com/tractis
--
David Garcia
CTO
Tractis - Online contracts you can enforce
http://www.tractis.com
--
Tel: [phone] (ext. 260)
Email: david.garcia@... <mailto:david.garcia@...>
Blog: http://blog.negonation.com
Twitter: http://twitter.com/tractis
------------------------------------------------------------------------
_______________________________________________
specs mailing list
specs@...
http://openid.net/mailman/listinfo/specs

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

--
David Garcia
CTO

Tractis - Online contracts you can enforce
http://www.tractis.com
--
Tel: [phone] (ext. 260)

Email: david.garcia@...
Blog: http://blog.negonation.com
Twitter: http://twitter.com/tractis

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