[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]