Digital signatures use cryptographic techniques to protect the integrity of information. The key used to sign data is typically controlled by a single entity and so the creation of a signature can be directly traced to the owner of the key. The validation of a signature includes not only the cryptographic processing, but also the determination that a key was trusted to sign a specific piece of information. The trust in a key is determined by the validation of other signed statements, or certificates, that describe the appropriate usage of the public key. This position paper examines requirements and possible approaches to fully support the validation of XML signatures.
Digital signatures, like a hand written signature, do not inherently carry meaning. When a document is signed, it could imply that: "I created this", "I approve" or "I agree to pay". Without additional annotation, a written or digital signature is ambiguous. Explicit semantics for the meaning of a signature need to be part of the signed document. The signature semantics could be carried in the signed document or as part of the signature.
The cryptographic correctness of a digital signature is determined by the following steps:
1) Use the cryptographic algorithm parameter definitions in the signature to determine: the appropriate hash algorithm, signature algorithm, signature format, asymmetric algorithm parameters and public key to use in the validation process.
2) Use the appropriate hash algorithm on a canonical representation of the signed data.
3) Use the appropriate algorithms and public key to create a digital signature over the hashed information.
4) Compare the newly computed signature to the attached signature. The validation fails at this point if they are not the same.
5) Determine if the public key used to create the signature was trusted for this specific signature application. This validation step might also include: ensuring that the key was not revoked, checking that the key is in a certificate that is valid or checking policy restrictions in an X.509 certificate.
This last step has not been fully addressed in current proposals for XML digital signatures. X.509 certificates could be used to support revocation and validity periods. X.509 certificates current do not support a means to determine if the usage of particular key was appropriate for a specific XML application.
The authority to sign data is dependent on the schema and contents of the signed object. One key might be trusted to assign e-mail address information and another to sign e-checks. Additional mechanisms are required to distribute and manage this application specific trust.
X.509 could be modified to include extensions that capture policy restrictions for specific XML schemas. XML could also be used to define authorization mechanisms that would bind trust for specific schemas to public keys.
Trust could be assigned and delegated using signed XML. Statements would be created that delegate a range of trust in a particular schema to a specific key. This would allow all XML related constraints on key usage to be expressed in XML.
The management of trust can be formulated into the assignment of rights to make statements in specific ranges. Delegation of rights can be granted for ranges of the target resource and property values.
The syntax of a signed delegation statement is similar to that of a signed object. Signatures on objects are of the form: "In {schema}, {key_holder} says {object}has {property}". Delegation is of the form: "In {schema}, {key_holder-1} grants {key_holder-2}the rights to make statements in {object_range}{property_range}".
Signed XML should provide a means to not only sign a resouce, but to also carry information that supports the evaluation of the signature semantics.
Signed XML should provide mechanisms to support the complete validation of a digital signatures. This validation needs to include the processing of constraints on key usage specific to an application. These constraints are best expressed in XML.
The application specific key usage constraints should be formulated as signed authorization statements. The signed authorization statements would then support the self consistent usage of XML in all of the schema specific validation processing.