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: 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]