RE: [xri] Very rough algorithm outline

["Drummond Reed" <drummond.reed@cordance.net>]

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