[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xri] Very rough algorithm outline
Thank you, Drummond. I just feel that we need to provide a solution with the spec even though we may not obliged to do so. With my little research, I could not find any solution to offer to developers. Tatsuki (6/17/09 12:31 PM), Drummond Reed wrote: > 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]