No subject
Fri Jun 12 00:51:43 UTC 2009
possible,<br>
so if we can stick to XML DSig, that's great.<br>
<br>
Now, here is another question then.<br>
<br>
If libraries with decent API becomes available to each language,<br>
written in that language, and is tested for compatibility to each other,<br=
>
would you be amiable to this constrained form of XML DSig?<br>
<br>
=3Dnat<br>
<br>
On Thu, 11 Jun 2009 16:14:56 +0200, David Garcia <<a href=3D"mailto:davi=
d.garcia at tractis.com">david.garcia at tractis.com</a>><br>
wrote:<br>
<div><div></div><div class=3D"h5">> Hi Hans,<br>
><br>
> this project offers a set of wrappers over xmlsec library used on many=
<br>
c++<br>
> envs. I used it a lot and their equivalent in Java for some years on<b=
r>
> critical production envs and they're very mature.<br>
><br>
> Dealing with xml data as opaque bits (a simplified xml version of CMS<=
br>
> signature containers) instead of interpreting the infoset as proposed<=
br>
will<br>
> be a much simpler approach because it eliminates the need of using c14=
n<br>
> and<br>
> transform algorithms (not mandatory but recommended on some scenarios)=
.<br>
><br>
> Maybe this simpler approach will fit for message exchange.<br>
><br>
> Best regards<br>
><br>
> Dave Garcia<br>
><br>
><br>
> 2009/6/11 Hans Granqvist <<a href=3D"mailto:hans at granqvist.com">han=
s at granqvist.com</a>><br>
><br>
>> Perhaps someone from VeriSign (Barry? Gary?) can comment on the<br=
>
> viability<br>
>> of<br>
>> <a href=3D"http://xmlsig.sourceforge.net/" target=3D"_blank">http:=
//xmlsig.sourceforge.net/</a><br>
>><br>
>> Hans<br>
>><br>
>><br>
>><br>
>> On Wed, Jun 10, 2009 at 11:54 PM, John Panzer<<a href=3D"mailto=
:jpanzer at acm.org">jpanzer at acm.org</a>> wrote:<br>
>> > My general impression is that something that requires two pie=
ces of<br>
>> software<br>
>> > to agree on an exact, bit for bit infoset representation of a=
n XML<br>
>> document<br>
>> > in order to get security to work is a poor idea. =A0I have se=
en no wide<br>
>> > deployments/usage of DSig in Atom feeds -- despite it being p=
art of<br>
> the<br>
>> spec<br>
>> > -- and many complaints about how it's not possible to get=
it to work<br>
>> > reliably given the software stacks currently in use. =A0The d=
ifficulties<br>
>> with<br>
>> > canonicalization-for-signing in OAuth implementations have al=
so<br>
>> reinforced<br>
>> > my belief that it's much better to err on the side of the=
robust and<br>
>> simple.<br>
>> ><br>
>> > Signing a stream of uninterpreted bytes cuts out a whole slew=
of<br>
> failure<br>
>> > modes, and the ones that remain are debuggable -- the bytes m=
atch or<br>
> they<br>
>> > don't, and standard tools can tell you which. =A0It means=
it's possible<br>
> to<br>
>> > verify a signature with curl + a command line utility. =A0The=
se are all<br>
>> very<br>
>> > good things.<br>
>> ><br>
>> > (As a side note, it would also make the content type orthogon=
al to the<br>
>> > signature code -- this is a good thing.)<br>
>> ><br>
>> > So, +1 for the simplest form of signing that could possibly w=
ork.<br>
>> ><br>
>> > -John<br>
>> ><br>
>> ><br>
>> > Johannes Ernst wrote:<br>
>> ><br>
>> > I proposed something I called XML-RSig for similar reasons a =
few years<br>
>> ago:<br>
>> ><br>
>> <a href=3D"http://netmesh.info/jernst/Technical/really-simple-xml-=
signatures.html" target=3D"_blank">http://netmesh.info/jernst/Technical/rea=
lly-simple-xml-signatures.html</a><br>
>> ><br>
>> > "RSig" for "Really simple Signature".<br>
>> ><br>
>> > The trouble for OpenID and XRD and so forth is that it is not=
our core<br>
>> > competency -- and shouldn't be -- to innovate around thin=
gs that<br>
> really<br>
>> > aren't our business. Signing XML documents isn't our =
business.<br>
>> ><br>
>> > On the other hand, the people whose business it should be som=
ehow seem<br>
> to<br>
>> be<br>
>> > asleep at the wheel, as the problems are well-known and someh=
ow aren't<br>
>> being<br>
>> > addressed, and haven't for years.<br>
>> ><br>
>> > It seems to me that the best way out of this conundrum is:<br=
>
>> > 1. to foresee, architecturally, the use of several different =
ways of<br>
>> > constructing signatures, as the matter clearly isn't sett=
led<br>
>> > 2. to make sure that high-end approaches (like XML-DSIG) work=
well,<br>
> but<br>
>> > low-end approaches (like XML-RSIG) work just as well<br>
>> > 3. to maintain a best practices document that says "toda=
y, choice X is<br>
>> your<br>
>> > best bet, and we say that because based on our market researc=
h, X has<br>
> the<br>
>> > highest market share in terms of implementors today."<br=
>
>> ><br>
>> > As we all know, any problem in computer science can be solved=
by<br>
> adding a<br>
>> > level of indirection. This may well be one of those cases.<br=
>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> > Johannes Ernst<br>
>> > NetMesh Inc.<br>
>> ><br>
>> ><br>
>> > ________________________________<br>
>> ><br>
>> ><br>
>> ><br>
>> > ________________________________<br>
>> ><br>
>> > =A0<a href=3D"http://netmesh.info/jernst" target=3D"_blank">h=
ttp://netmesh.info/jernst</a><br>
>> ><br>
>> ><br>
>> ><br>
>> > ________________________________<br>
>> > _______________________________________________<br>
>> > specs mailing list<br>
>> > <a href=3D"mailto:specs at openid.net">specs at openid.net</a><br>
>> > <a href=3D"http://openid.net/mailman/listinfo/specs" target=
=3D"_blank">http://openid.net/mailman/listinfo/specs</a><br>
>> ><br>
>> ><br>
>> > _______________________________________________<br>
>> > specs mailing list<br>
>> > <a href=3D"mailto:specs at openid.net">specs at openid.net</a><br>
>> > <a href=3D"http://openid.net/mailman/listinfo/specs" target=
=3D"_blank">http://openid.net/mailman/listinfo/specs</a><br>
>> ><br>
>> ><br>
>> _______________________________________________<br>
>> specs mailing list<br>
>> <a href=3D"mailto:specs at openid.net">specs at openid.net</a><br>
>> <a href=3D"http://openid.net/mailman/listinfo/specs" target=3D"_bl=
ank">http://openid.net/mailman/listinfo/specs</a><br>
>><br>
><br>
><br>
><br>
> --<br>
> David Garcia<br>
> CTO<br>
><br>
> Tractis - Online contracts you can enforce<br>
> <a href=3D"http://www.tractis.com" target=3D"_blank">http://www.tracti=
s.com</a><br>
> --<br>
> Tel: (34) 93 551 96 60 (ext. 260)<br>
><br>
> Email: <a href=3D"mailto:david.garcia at tractis.com">david.garcia at tracti=
s.com</a><br>
> Blog: <a href=3D"http://blog.negonation.com" target=3D"_blank">http://=
blog.negonation.com</a><br>
> Twitter: <a href=3D"http://twitter.com/tractis" target=3D"_blank">http=
://twitter.com/tractis</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>David Garci=
a<br>CTO<br><br>Tractis - Online contracts you can enforce<br><a href=3D"ht=
tp://www.tractis.com">http://www.tractis.com</a><br>--<br>Tel: (34) 93 551 =
96 60 (ext. 260) <br>
<br>Email: <a href=3D"mailto:david.garcia at tractis.com">david.garcia at tractis=
.com</a><br>Blog: <a href=3D"http://blog.negonation.com">http://blog.negona=
tion.com</a><br>Twitter: <a href=3D"http://twitter.com/tractis">http://twit=
ter.com/tractis</a><br>
--000e0cd6ae5817e385046c22c783--
More information about the specs
mailing list