Re: [dss] Use cases

[Trevor Perrin <trevp@trevp.net>]

Now that we've got a bunch of use cases, here's a stab at trying to extract 
some requirements.  I think a lot of the use cases are already 
requirements, or could be factored into requirements easily, and then the 
remaining use cases could be viewed in terms of which requirements apply to 
them.  This may or may not be helpful, I dunno..

Requirements and Options for the Use Cases
-------------------------------------------
On the left are "requirements axes", and on the right are the different 
values each axis could take for different use cases.

to-be-signed format   : XML, binary
DSS protocol used     : yes, no
   input preparation   : raw, hashed, blinded [*]
   input delivery      : direct, URI [*]
signature format      : XML-DSIG, CMS, PGP, other
signature position    : enveloping, enveloped, detached
identified requestor  : yes, no
signing time          : stamped, marked, none
periodic re-signing   : yes, no

[*] These 2 requirements only apply when the DSS protocol is used.  The DSS 
protocol might not be used in cases where the to-be-signed message is 
signed by an MTA or SOAP router that it is passing through, or in the Court 
Filings use case.  In all these cases, the data is signed in transit, so 
there's no need for a request/response protocol by the originator.

These requirements would absorb the following use-cases:

SOAP Signing -> to-be-signed format
Identified Requestor -> identified requestor
Long Term Corporate Signatures -> signing time, periodic re-signing
Non-XML Data Signing -> to-be-signed format, signature format
Client Side Hashing  -> input preparation
Time stamping / Time marking -> signing time, periodic re-signing

Some requirements can be grouped under those above: for example, anything 
about transforms is specific to the XML to-be-signed format, and anything 
about signature and manifest references is specific to the XML-DSIG 
signature format.

Some other requirements are more generic: for example, 2.2.3, 2.2.4, and 
2.2.5 about the validation service apply no matter what the signature 
format or anything else is.

The remaining concrete use cases (minus Delegated Signature Verification, 
cause that's a separate thing, and Individual Signatures which is a little 
vague) are:
Corporate Seal
eNotarization
Court Filings
Email Signing/Verifying (from Non-XML Data Signing)
Code Signing/Verifying (from Non-XML Data Signing)

In terms of the requirements, we have:

Corporate Seal
to-be-signed format  : XML, binary (either one)
DSS protocol used    : yes
   input preparation  : raw (so the corporation can archive)
   input delivery     : direct, URI
signature format     : XML-DSIG (perhaps CMS as well?)
signature position   : enveloping, enveloped, detached
identified requestor : no (only the corporation's identity is important)
signing time         : stamped, marked, none (leave it optional)
periodic re-signing  : yes, no (leave it optional)

eNotarization
to-be-signed format  : XML, binary
DSS protocol used    : yes
   input preparation  : raw (so the notary can review)
   input delivery     : direct, URI
signature format     : XML-DSIG (perhaps CMS as well?)
signature position   : enveloping, enveloped, detached
identified requestor : yes (the requestor's identity is important)
signing time         : stamped, marked
periodic re-signing  : yes, no

Court Filings
to-be-signed format  : XML, binary
DSS protocol used    : no (cause the document is signed in transit)
signature format     : XML-DSIG
signature position   : enveloping, enveloped, detached
identified requestor : yes (the filer's identity is important)
signing time         : stamped, marked
periodic re-signing  : no

Email Signing/Verifying
to-be-signed format  : binary
DSS protocol used    : yes, no [*]
   input preparation  : hashed (for efficiency and privacy)
   input delivery     : direct
signature format     : CMS, PGP
signature position   : enveloping, detached[**]
identified requestor : yes (the sender's identity is important)
signing time         : stamped, marked
periodic re-signing  : no
[*] No when the signature is being applied by an MTA on an email passing 
through.  Yes when the signature is being applied by an MUA (email client), 
which must contact a DSS to get a signature.
[**] to allow opaque- or clear-signed S/MIME messages

Code Signing/Verifying
to-be-signed format  : binary
DSS protocol used    : yes
   input preparation    : raw, hashed
   input delivery       : direct
signature format     : CMS
signature position   : enveloping
identified requestor : no
signing time         : stamped, marked
periodic re-signing  : no

So eNotarization is the same as Corporate Seal but with the requestor's 
name included, and with signing time required.  Court Filings is the same 
as eNotarization, but the data is signed in transit, so the 
request/response protocol isn't needed, and periodic re-signing isn't needed.

Code Signing and Email Signing both deal with binary data, but in Code 
Signing the requestor's name isn't included, the CMS format is mandated, 
detached signatures aren't used, and the to-be-signed data may be presented 
raw as well as hashed, since the code signing service may want to 
archive/review it.

Trevor




----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>