OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[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]