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 <sakim...@gmail.com <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
<david.gar...@tractis.com <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 <h...@granqvist.com
<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 Panzer<jpan...@acm.org
<mailto: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 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 <mailto:specs@openid.net>
>> > http://openid.net/mailman/listinfo/specs
>> >
>> >
>> > _______________________________________________
>> > specs mailing list
>> > specs@openid.net <mailto:specs@openid.net>
>> > http://openid.net/mailman/listinfo/specs
>> >
>> >
>> _______________________________________________
>> specs mailing list
>> specs@openid.net <mailto: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 <mailto:david.gar...@tractis.com>
> Blog: http://blog.negonation.com
> Twitter: http://twitter.com/tractis
--
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 <mailto: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
_______________________________________________
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
