[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xri] Very rough algorithm outline
Hello, David Garcia helped us to find candidates xmlsig(xmlsec) implementations for scripting languages in theOpenID list. He showed us an example, so I tried myself with Ruby that I am familiar with. There are two ways to make xmlsig(xmlsec) run: 1. Install the xmlsec library and make a wrapper with swig 2. Install Hans's xmlsig Both methods are technically the same and use a swig wrapper. The difference is how to install it. 1. is using "rubygems" which is a package manger in Ruby and most ruby users use to install ruby libraries they need to develop apps. There is a swig wrapper implemented in github(the repository you can run "gem install" directly against it.). I could install it with no errors; however, I got en error when I include(require) it in a code. I contacted who is developing it. He told me that it was incomplete and wait for a stable release. 2. is developed by Hans of Verisign. This is the only way to run xmlsig in Ruby for most people without developing a sig wrapper themselves. I did three tests. The unit test comes with this implementation worked. But against the SAML assertion generated by the IDP(Java-based) I have here didn't work. It may be caused by another reason. I need further inspections. But this implementation does not return useful values when I call methods through the swig wrapper. It is very hard to troubleshoot. I have learned two points from this little experiment. First, the installation for xmlsig can be a issue. There aren't many choices either. If I think of how to install the OpenID library in ruby(just type "gem install ruby-openid"), it is way more difficult. This could be a barrier for adoption. Probably we should assume that people expects the same level of ease to install. Second, the cost to impose c14n to developers is too high. I have found one canonicalizer written purely in Ruby, but it didn't work. And the way describe above doesn't guarantee if it interoperates other canonicalizers but Hans's. If we assume that most of web developers do c14n only for XRD signing and doesn't use it for any other purposes(but likely do digital signatures), I think we are asking and expecting too much to them. It is obviously that c14n is the only issue. I still believe that eliminating it is sound choice to drive adoption of XRD with signing. Tatsuki (6/12/09 12:39 PM), Drummond Reed wrote: > Scott, I don't know about anyone else, but this is tremendously helpful for > me to get a sense of exactly what is involved. > > I would love to see this become part of one of the series of blog posts or > web guides that are published on XRD and XRD signatures once the spec is > ready. > > =Drummond > >> -----Original Message----- >> From: Scott Cantor [mailto:cantor.2@osu.edu] >> Sent: Friday, June 12, 2009 10:30 AM >> To: 'XRI TC' >> Subject: [xri] Very rough algorithm outline >> >> Since signing is less frequent, I'll try and sketch out a brute force >> verification. Obviously the c14n bits are the same for signing. This is >> just >> a guess about what the rough outline would be if I was trying this from >> scratch. >> >> It's a DOM-based algorithm, and I don't use SAX so I don't know enough >> about >> it to comment. I know the profile can be streamed, though. >> >> 1. Parse the XRD into a DOM tree in the usual fashion. Check it over as >> much >> as you can before bothering with the signature. E.g. If there's some kind >> of >> "claimed" identity for the signer, you can see if that identity is even >> trustable before you bother with any other work. >> >> 2. Find the ds:Signature and examine it to be sure it conforms to the >> profile, such as: >> >> - ensure the CanonicalizationAlgorithm and signature algorithm are >> acceptable >> - ensure it has only one Reference and that URI is an ID reference to the >> xml:id in the root element of the XRD. >> - ensure the digest algorithm is acceptable >> - check for Transforms and make sure it has only two, an Enveloped >> transform >> followed by an acceptable c14n transform >> >> Personally I wouldn't even bother with supporting inclusive c14n. Will >> could >> adjust the profile to mandate exclusive. >> >> 3. Compute the Reference Digest >> >> - Canonicalize the subtree starting at the XRD root element, knowing to >> skip >> the ds:Signature (see below) >> - Digest the result and verify it against the ds:DigestValue >> >> 4. Obtain the signing key >> >> - Either rely on known keys or resolve a signing key from the ds:KeyInfo >> and >> validate that it's acceptable. >> >> 5. Compute the Signature >> >> - Canonicalize the subtree starting at the ds:SignedInfo element (see >> below) >> - Digest the result and compute the signature with the trusted >> verification >> key, and verify it against the ds:SignatureValue. >> >> >> That's it minus the canonicalization step, which is roughly the outline I >> pointed to here: http://www.w3.org/TR/xml-exc-c14n/#sec-Implementation >> >> In slightly less technical and more verbose language: >> >> 1. Check for an InclusiveNamespaces element parameter to the algorithm >> with >> a PrefixList, and tokenize the list. >> >> 2. Establish a stack of elements and the namespace declarations that are >> "in >> scope" at each processing stage as a result of processing the elements. >> It's >> a mapping from element to namespaces in scope that you pop once you return >> from processing the element's children. >> >> 3. Recurse over the subtree operating on each element as follows: >> >> a. Is this a signature Reference and is this the ds:Signature element? If >> so, skip it and return. >> >> b. Output the element node by following the Inclusive C14N spec, which >> tells >> you how to format it, how to order its attributes properly, what to do >> with >> text nodes, processing instructions, etc. I'm not going to repeat that >> here, >> but that part can easily be copied from existing libraries, it's not the >> complex part. The *exception* to the normal rules is the handling of XML >> namespace attributes. >> >> c. For non-default namespace declarations, you check that both of these >> conditions are true before you include it in the element: >> - the element or its attributes contain the prefix OR it's in the >> InclusiveNamespaces PrefixList >> - the current stack of in-scope namespaces doesn't include it >> already >> That applies to both namespaces the element itself declares and any that >> are >> explicitly used by the element or attribute names themselves. >> >> d. For xmlns="" (clearing the default namespace), there are a couple of >> simple checks to determine if it needs to be output, which you can see in >> step 3.3 of http://www.w3.org/TR/xml-exc-c14n/#sec-Implementation. It >> doesn't come up much since specs like this don't rely on unqualified >> elements very often. >> >> e. Push all of the newly output namespace declarations onto the stack with >> the element and process each of its child elements recursively. >> >> f. After you come back, pop the namespace stack. >> >> -- Scott >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this mail list, you must leave the OASIS TC that >> generates this mail. Follow this link to all your TCs in OASIS at: >> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >
--- Begin Message ---Hi Nat,
- From: David Garcia <david.garcia@tractis.com>
- To: Nat Sakimura <sakimura@gmail.com>
- Date: Sat, 13 Jun 2009 14:35:01 +0200
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@gmail.com>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,=natOn Sat, Jun 13, 2009 at 3:01 AM, David Garcia <davebcn@gmail.com> 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@nri.com> 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@gmail.com <mailto:sakimura@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.garcia@tractis.com <mailto:david.garcia@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 <hans@granqvist.com
<mailto:hans@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<jpanzer@acm.org
<mailto:jpanzer@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.garcia@tractis.com <mailto:david.garcia@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.garcia@tractis.com <mailto:david.garcia@tractis.com>
Blog: http://blog.negonation.com
Twitter: http://twitter.com/tractis
------------------------------------------------------------------------
_______________________________________________
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.garcia@tractiscom
Blog: http://blog.negonation.com
Twitter: http://twitter.com/tractis
--- End Message ---
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]