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


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]