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


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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]