[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [dss] Use case: non-XML signing
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC