[OpenID] Signing method for XRD

Nat Sakimura sakimura at gmail.com
Thu Jun 11 10:20:37 UTC 2009


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 <jernst+openid.net@
netmesh.us> 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20090611/1c84e727/attachment.htm>


More information about the specs mailing list