[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] XML DSig
Will, yes, I'll add it to the agenda I'm just about to send out. =Drummond > -----Original Message----- > From: Will Norris [mailto:will@willnorris.com] > Sent: Wednesday, May 27, 2009 10:08 AM > To: XRI TC > Subject: Re: [xri] XML DSig > > I've been talking with Scott about this a bit the last couple of days > as well, and he's indicated a way of doing XML Signatures without > needing to do full c14n. I didn't entirely understand all of it > (maybe some of you are already familiar with it), but have pasted his > response below. He's volunteered to join the TC call tomorrow if we > want to pursue this further. If we can find a way to do XML DSig in a > way that is reasonably supported among the major programming > languages, it would make this whole thing much cleaner (not having > four different ways to deliver the signature). > > Drummond, could you add that to the agenda? > > -will > > > On May 27, 2009, at 9:50 AM, Scott Cantor wrote: > > > Basically I'm assuming what you want here is a single enveloped > > Signature > > that signs the whole XRD document? All you need for that is an ID > > attribute > > in the XRD element (which I forgot to mention you should add anyway) > > and a > > profile like SAML's that requires a single ID-based reference to the > > XRD > > element and allows only Enveloped and the Excl C14N transform. > > > > If you know that's what you have, implementing it isn't that hard. > > When you > > hit the c14n transform, all you do is walk the tree starting at the > > referenced element, order the attributes per the c14n spec, keep a > > namespace > > stack (and follow the exclusive c14n rules for them), and skip the > > Signature > > element. > > > > When you digest the SignedInfo, you do the same thing, because it's > > also > > just a simple subtree. > > > > If you're only supporting that use case, you can brute force all of > > it on > > the verifying end by examining the transforms ahead of time (which > > you do > > anyway), and then computing the octets up front and just feeding > > them to a > > digest. > > > > Those of us with working implementations don't have to do anything > > special > > because it's still compliant with the spec, but people using > > deficient tools > > can write it themselves, which they'd have to do anyway with a non- > > standard > > approach. > > > > I suspect all of that could be factored into a library if you > > supported only > > signatures that followed that "pattern". Even WSS signatures follow > > it to > > some degree if they rely on ID-based references or very limited > > XPaths. > > > > -- 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]