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] Very rough algorithm outline


Tatsuki,

Thanks for the detailed illustration.

So if you and Nat (and possibly Dirk) all feel that we must offer something
simpler than constrained XML dSig, it's clear the issue of XRD signatures is
still not settled.

I will put it on the agenda for tomorrow's telecon. Again, I urge everyone
concerned with this issue to attend, including Scott if he can make it.

We must come to a conclusion the TC can live with and that can lead to broad
adoption.

=Drummond 

> -----Original Message-----
> From: Tatsuki Sakushima [mailto:tatsuki@nri.com]
> Sent: Wednesday, June 17, 2009 11:42 AM
> To: 'XRI TC'
> Cc: Drummond Reed; 'Scott Cantor'
> Subject: Re: [xri] Very rough algorithm outline
> 
> Hello,
> 
> David Garcia helped us to find candidates xmlsig(xmlsec) implementations
> for scripting languages in theOpenID list. He showed us an example, so I
> tried myself with Ruby that I am familiar with.
> 
> There are two ways to make xmlsig(xmlsec) run:
> 
> 1. Install the xmlsec library and make a wrapper with swig
> 2. Install Hans's xmlsig
> 
> Both methods are technically the same and use a swig wrapper. The
> difference is how to install it.
> 
> 1. is using "rubygems" which is a package manger in Ruby and most ruby
> users use to install ruby libraries they need to develop apps. There is a
> swig wrapper implemented in github(the repository you can run "gem
> install" directly against it.). I could install it with no errors;
> however, I got en error when I include(require) it in a code. I contacted
> who is developing it. He told me that it was incomplete and wait for a
> stable release.
> 
> 2. is developed by Hans of Verisign. This is the only way to run xmlsig in
> Ruby for most people without developing a sig wrapper themselves. I did
> three tests. The unit test comes with this implementation worked. But
> against the SAML assertion generated by the IDP(Java-based) I have here
> didn't work.  It may be caused by another reason. I need further
> inspections. But this implementation does not return useful values when I
> call methods through the swig wrapper. It is very hard to troubleshoot.
> 
> I have learned two points from this little experiment. First, the
> installation for xmlsig can be a issue. There aren't many choices either.
> If I think of how to install the OpenID library in ruby(just type "gem
> install ruby-openid"), it is way more difficult. This could be a barrier
> for adoption. Probably we should assume that people expects the same level
> of ease to install. Second, the cost to impose c14n to developers is too
> high. I have found one canonicalizer written purely in Ruby, but it didn't
> work. And the way describe above doesn't guarantee if it interoperates
> other canonicalizers but Hans's. If we assume that most of web developers
> do c14n only for XRD signing and doesn't use it for any other purposes(but
> likely do digital signatures), I think we are asking and expecting too
> much to them. It is obviously that c14n is the only issue. I still believe
> that eliminating it is sound choice to drive adoption of XRD with signing.
> 
> Tatsuki
> 
> (6/12/09 12:39 PM), Drummond Reed wrote:
> > Scott, I don't know about anyone else, but this is tremendously helpful
> for
> > me to get a sense of exactly what is involved.
> >
> > I would love to see this become part of one of the series of blog posts
> or
> > web guides that are published on XRD and XRD signatures once the spec is
> > ready.
> >
> > =Drummond
> >
> >> -----Original Message-----
> >> From: Scott Cantor [mailto:cantor.2@osu.edu]
> >> Sent: Friday, June 12, 2009 10:30 AM
> >> To: 'XRI TC'
> >> Subject: [xri] Very rough algorithm outline
> >>
> >> Since signing is less frequent, I'll try and sketch out a brute force
> >> verification. Obviously the c14n bits are the same for signing. This is
> >> just
> >> a guess about what the rough outline would be if I was trying this from
> >> scratch.
> >>
> >> It's a DOM-based algorithm, and I don't use SAX so I don't know enough
> >> about
> >> it to comment. I know the profile can be streamed, though.
> >>
> >> 1. Parse the XRD into a DOM tree in the usual fashion. Check it over as
> >> much
> >> as you can before bothering with the signature. E.g. If there's some
> kind
> >> of
> >> "claimed" identity for the signer, you can see if that identity is even
> >> trustable before you bother with any other work.
> >>
> >> 2. Find the ds:Signature and examine it to be sure it conforms to the
> >> profile, such as:
> >>
> >> - ensure the CanonicalizationAlgorithm and signature algorithm are
> >> acceptable
> >> - ensure it has only one Reference and that URI is an ID reference to
> the
> >> xml:id in the root element of the XRD.
> >> - ensure the digest algorithm is acceptable
> >> - check for Transforms and make sure it has only two, an Enveloped
> >> transform
> >> followed by an acceptable c14n transform
> >>
> >> Personally I wouldn't even bother with supporting inclusive c14n. Will
> >> could
> >> adjust the profile to mandate exclusive.
> >>
> >> 3. Compute the Reference Digest
> >>
> >> - Canonicalize the subtree starting at the XRD root element, knowing to
> >> skip
> >> the ds:Signature (see below)
> >> - Digest the result and verify it against the ds:DigestValue
> >>
> >> 4. Obtain the signing key
> >>
> >> - Either rely on known keys or resolve a signing key from the
> ds:KeyInfo
> >> and
> >> validate that it's acceptable.
> >>
> >> 5. Compute the Signature
> >>
> >> - Canonicalize the subtree starting at the ds:SignedInfo element (see
> >> below)
> >> - Digest the result and compute the signature with the trusted
> >> verification
> >> key, and verify it against the ds:SignatureValue.
> >>
> >>
> >> That's it minus the canonicalization step, which is roughly the outline
> I
> >> pointed to here: http://www.w3.org/TR/xml-exc-c14n/#sec-Implementation
> >>
> >> In slightly less technical and more verbose language:
> >>
> >> 1. Check for an InclusiveNamespaces element parameter to the algorithm
> >> with
> >> a PrefixList, and tokenize the list.
> >>
> >> 2. Establish a stack of elements and the namespace declarations that
> are
> >> "in
> >> scope" at each processing stage as a result of processing the elements.
> >> It's
> >> a mapping from element to namespaces in scope that you pop once you
> return
> >> from processing the element's children.
> >>
> >> 3. Recurse over the subtree operating on each element as follows:
> >>
> >> a. Is this a signature Reference and is this the ds:Signature element?
> If
> >> so, skip it and return.
> >>
> >> b. Output the element node by following the Inclusive C14N spec, which
> >> tells
> >> you how to format it, how to order its attributes properly, what to do
> >> with
> >> text nodes, processing instructions, etc. I'm not going to repeat that
> >> here,
> >> but that part can easily be copied from existing libraries, it's not
> the
> >> complex part. The *exception* to the normal rules is the handling of
> XML
> >> namespace attributes.
> >>
> >> c. For non-default namespace declarations, you check that both of these
> >> conditions are true before you include it in the element:
> >> 	- the element or its attributes contain the prefix OR it's in the
> >> InclusiveNamespaces PrefixList
> >> 	- the current stack of in-scope namespaces doesn't include it
> >> already
> >> That applies to both namespaces the element itself declares and any
> that
> >> are
> >> explicitly used by the element or attribute names themselves.
> >>
> >> d. For xmlns="" (clearing the default namespace), there are a couple of
> >> simple checks to determine if it needs to be output, which you can see
> in
> >> step 3.3 of http://www.w3.org/TR/xml-exc-c14n/#sec-Implementation. It
> >> doesn't come up much since specs like this don't rely on unqualified
> >> elements very often.
> >>
> >> e. Push all of the newly output namespace declarations onto the stack
> with
> >> the element and process each of its child elements recursively.
> >>
> >> f. After you come back, pop the namespace stack.
> >>
> >> -- 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
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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]