[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xri] xml dsig profile
For the record, I agree that if we want to start having multiple objects in a single XML object with different signatures, we should use XML DSIG and be done with it. I don't think that's a real use case for XRDs. On Tue, Mar 3, 2009 at 12:32 PM, =JeffH <Jeff.Hodges@kingsmountain.com> wrote: > 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 > > > > --------------------------------------------------------------------- > 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 > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]