hybrid solution for process specification digests and CPP/CPA signatures

[Tony Weida <TonyW@EDIFECS.COM>]

This note documents another concern, then makes a new proposal that I
believe addresses everyone's outstanding concerns.

Concern: A party to a CPA will generally want assurance that both parties
have agreed to exactly the same set of process specifications.  That
assurance can be provided for each process specification by agreeing to the
digest (and other) algorithms, along with the resulting digest value.
However, there may be a problem with placing the digest information only in
signatures, since signatures are applied to a CPA *after* the CPA is agreed
to and the signatures may not be considered part of the agreement itself --
there arises the possibility of different digest information in different
signatures, leading to various unnecessary complications.  For one example
amony many:

1. Parties A and B agree to a CPA 
2. Party A signs
3. One of the referenced process specifications changes
4. Party B signs

The following proposal meets all of my concerns by (1) ensuring that each
ProcessSpecification reference, including digest and transform information,
is uniquely defined within a CPP/CPA such that each party signs exactly the
same form of exactly the same process specifications, and (2) allowing
digests to be validated without requiring signatures.  I believe it meets
Chris' concerns by taking advantage of existing XML DSIG machinery to
simplify implementation, while allowing but not requiring any additional
implementation capabilities.  I believe it meets Marty's desire to identify
any altered process specifications that may have contributed to an invalid
signature.  Something for everyone!

1. Each ProcessSpecification element SHALL contain either (a) one
ds:Reference element formulated according to the XML Digital Signature
specification [XMLDSIG], or (b) one xlink:href attribute and one xlink:type
attribute with a value of "locator".  In case the document is signed, it
SHOULD/MUST use the ds:Reference element.
  
(Note that according to XMLDSIG, a Reference element MUST include one
ds:DigestMethod and one ds:DigestValue element, and may include ds:Transform
elements.  Choice b allows the digest information to be omitted in case the
document is unsigned. Eliminating choice b would be okay with me.)

2. In case a CPP/CPA is signed, each signature SHALL incorporate a verbatim
copy of every ProcessSpecification element's ds:Reference element.

3. If a CPP/CPA Signature is found to be invalid, software MAY validate the
Reference elements within that Signature to determine which ones, if any,
contributed to the invalidity.

4. In case a CPP/CPA is unsigned, software MAY nonetheless validate the
Reference elements within ProcessSpecification elements and report any
exceptions.

Open for Discussion:

- In point one, is it SHOULD or MUST?  I'm inclined towards MUST.

- Do we REQUIRE the c14n transform for canonicalization of each Reference
within a ProcessSpecification?

- (How) do we restrict the transforms that may be applied to a
ProcessSpecification?  One possibility is to forbid transforms that alter
the canonical form of a document.

Cheers,
Tony