[dss] Use case: non-XML signing

[merlin hughes <merlin@baltimore.ie>]

I would like to put out, for consideration, the use case of
generating and validating non-XML signature formats.

Specific instances:

. Validating / generating S/MIME signatures
. Validating / generating signed code (e.g., JAR files)
. Validating / generating proprietary formats

For example, a simple email client that receives an S/MIME
email can display the MIME content but cannot handle the
signature, so it packages the mail up and submits it to the
DSS service for validation. Similarly, to send a signed email,
the client generates a MIME message, submits it to the service,
with authorization, and receives an S/MIME response that it
can send out.

For the signed code instance, developers within an organization
may not have access to signing keys; either because of
organizational policy, or because of the general code signing
policy. When code development is complete, the packaged code
can be submitted, with authorization, to a signing service
which returns a signed code package.

Supporting extensiblity for further proprietary formats
might help organizations transition from legacy internal
signed documents.

I'm not proposing that we actually define the processing of
any specific non-XML format, just that we consider supporting
signature typing, data packaging and extensibility so that a
DSS service could support these types of signature. I think
that presentation of the data to be signed and the receipt of
any resulting transformed data should probably be considered
alongside the XML signature reference processing issue.

Should this use case be accepted, it might suggest that
XMLDSIG be a signature type defined in its own document,
alongside a more agnostic DSS spec.

Merlin


-----------------------------------------------------------------------------
The information contained in this message is confidential and is intended
for the addressee(s) only.  If you have received this message in error or
there are any problems please notify the originator immediately.  The 
unauthorised use, disclosure, copying or alteration of this message is 
strictly forbidden. Baltimore Technologies plc will not be liable for
direct, special, indirect or consequential damages arising from alteration
of the contents of this message by a third party or as a result of any 
virus being passed on.

This footnote confirms that this email message has been swept for Content
Security threats, including computer viruses.
http://www.baltimore.com