Re: [dss] Identified Requester with single keypair/cert

[John Messing <jmessing@law-on-line.com>]

Trevor's posting is extremely useful in my opinion in pointing out some of the potentials of the single key signing use case as well as a need for authentication of the requestor. 

Another point that perhaps should be considered in the DSS standard if we do include a single server key use case, or at least as a warning to application developers, is the problem of heightened private key entropy. If a server signs continuously with a single asymmetric private key on behalf of multiple requestors, there is increased danger of successful attacks against the key or reverse factoring of it. There are methods for combatting those dangers, which also involve binding the requestor's identity to a signature in some ways that may be suggested by or related to the posting.

The court filing use case involves signed submissions to a government agency, court or other repository that may also include an infomediary acting as an agent for the filer and/or the agency or court. The submissions are intended to remain with the receiving entity as a permanent, filed record, whether distributed or shared with others. The court filing use case involves in part a single signing private key architecture that takes advantage of some of the protection and binding mechanisms for the server's private key alluded to above. I am scheduled to discuss the use case at the next TC call according to the 
agenda.

Upon reflection, I believe that I have one or more pending patent applications that may include claims related to a DSS single private key signing use case.  

If an OASIS Standard incorporating the court filing contribution is adopted by OASIS pursuant to the current DSS Technical Committee Charter, I will endeavor to license, for the purpose of implementing and complying with the required portions of a resulting OASIS DSS Standard, patent rights to necessary claims under reasonable and non-discriminatory terms and conditions to be established after such patent(s) are issued and final.

As used herein, necessary claims are claims or portions of claims that are infringed because there is no technically reasonable non-infringing alternative to infringement for implementing or complying with such DSS standard. 

John Messing
3900 E. Broadway, Suite 201
Tucson, AZ 85711
(520)547-7933 (v)
(520)547-7920 (f)
---------- Original Message ----------------------------------
From: Trevor Perrin <trevp@trevp.net>
Date:  Thu, 06 Feb 2003 13:48:29 -0800

>
>
>The Identified Requester use case had an interesting idea:
>
>"The Digital Signature Server may sign all data with its own private key 
>and simply include the name or identifier of the requester(s) within the 
>scope of the data that is signed."
>
>This raises some questions:
>  a) how to include a name within the signature (in XML DSIG, CMS, etc.)
>  b) what does the service's cert look like?
>
>For (a), both XML DSIG and CMS can have signed attributes in 
>signatures.  It would be easy to stick in a name, or maybe even a SAML 
>Assertion about the originator.
>
>For (b), RFC 3183 (DOMSEC) might be a guide.  It uses a naming convention 
>where a cert with a name like "domain-signing-authority@Acme.com" can apply 
>signatures with the semantics "this mail came from someone within this 
>domain".  An MTA can apply these signatures to outbound email.
>
>So maybe a "delegated-signing-authority@Acme.com" would be trusted to 
>produce signatures associated with a particular user in the Acme.com 
>domain.  An interesting point is that such a signature could be applied by 
>either an "inline" trusted third party like an MTA, or an "online" trusted 
>third party like a DSS service.
>
>So this is getting out of scope, but I guess my point is, if the group 
>wants to support the above case, it might be desirable to also push the 
>concepts of originator-associated signatures and delegated-signer certs, in 
>groups like ietf-smime or ietf-pkix.
>
>Trevor
>
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>
>