[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xri] xml dsig profile
Below's Scott's succinct summary of our rationale wrt the "SAMLv2.0 HTTP POST 'SimpleSign' Binding". =JeffH ------ Subject: RE: [xri] xml dsig profile From: "Scott Cantor" <cantor.2@osu.edu> Date: Tue, 3 Mar 2009 11:39:50 -0500 (08:39 PST) To: "'Peter Davis'" <peter.davis@neustar.biz>, "'Jeff Hodges'" <Jeff.Hodges@KingsMountain.com> Peter Davis wrote on 2009-03-03: > the XRI TC is looking at variations of the simple-sign work done for > the SSTC, and I have suggested that we should not introduce a new > model unless we are very compelled to do so. Unless you're working with a messaging model in which you're just trying to sign essentially everything you're expressing in XML, I doubt that it's a good model. Something that has to be composed of different pieces and potentially include signed objects and unsigned objects within the same document, which strikes me as a need for things like XRDS, probably needs to use XML Signature. > Can you provide any background wrt the model you choose > (optimizations, work-arounds, deployment experiences) that i can > reflect back to the XRI TC? I have no deployment experience with it. Far as I know, only AOL has used it a bit. Generally when people reject XML Signature, they've also rejected XML to begin with, and being able to solve the signing problem just changes the excuse they use. The model we chose was really to address two issues: - avoiding c14n as currently defined (note even for the "simple" spec, we had to go around a few times to come up with a workable signing model, so c14n is always a problem, even when you deal with data as a blob) - expressing the signature without using the ds:Signature element, because there's no way to build a signature Reference to a set of form elements in an HTML page The goal we had was to sign messages bound to HTML forms, so that didn't leave much in the way of existing options. I've raised that point with the W3C working group. I think it would be better if we could build references to parts of IETF protocol messages such as HTTP but still reuse the ds:Signature element and reference model. At the moment, that's pretty impossible to do. We weren't trying to solve the more general signing problem OAuth took on, but clearly one could reuse that piece of OAuth (which shouldn't be part of OAuth to begin with) to handle this kind of signing. In terms of implementing this, you need essentially all the same crypto dependencies you would need for XML Signature, and you end up calling into the raw PKCS1 signing code that the signature library would be using. We reused the ds:KeyInfo structure so that key material expression was consistent between XML and Simple signing in SAML. My impression from my participation in the W3C group right now is that they "get" the problem. Nobody is happy with c14n as currently defined, and there's a serious proposal [1] right now to essentially start over with a simpler spec. If that happens, I believe it would be a mistake to continue with these workarounds. -- Scott [1] http://www.w3.org/TR/2009/WD-xmldsig-simplify-20090226/ --- end
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]