RE: [dss] Groups - dss-requirements-1.0-draft-02.doc uploaded

["Gregor Karlinger" <gregor.karlinger@cio.gv.at>]

Hi all,

I would like to make some comments on the dss requirements draft:

1. Line 194ff: I think that CMS/PKCS#7 is widely used and therefore
   important enough to be considered explicitely. Formats apart
   from XMLDSIG and CMS I deem to be beyond the scope of this TC.

2. Line 201f: Is it necessary to distinguish between a string and
   a SAML assertion? The former can be seen as a subset of the
   latter. 

3. Line 217: There are additional use cases for time stamps (see
   the submision from Nick Pope: ETSI TS 101 903 (XAdES) [1]). 

4. Line 230f: The cited ETSI specifications contain many useful
   attributes. I think we should discuss in detail which of those
   a DS service must understand/must be able to apply.

5. Line 245ff: My interpretation of plain and transformed is as
   follows: Plain - the requester submits the data and instructions
   which transforms have to be applied by the service prior to 
   computing the digest; Transformed - the requester submits trans-
   form instructions together with the already transformed data, i.
   e. the service need not compute the transforms. Right?

6. Line 300: I cannot see any impressing arguments to support this.

7. Line 304ff: If we let the requester decide which dsig:References
   inside a dsig:SignedInfo should be verified, we are not conform
   with the processing model of XMLDSIG, which says that verifying
   a signature means verifying all References in SignedInfo. Regar-
   ding the verification of a dsig:Manifest, the requester should
   have the possibility to decide which dsig:References inside a
   dsig:Manifest should be verified; this makes sense taking into
   account the processing model of XMLDSIG.

8. Line 316ff: The question leaves open on which evidence the server
   bases its knowledge about the key compromise. In order to fullfil
   verification requests with a date in the past, the service must
   archive historical revocation information. Then it should be 
   possible for the service to determine the revocation status at
   the requested verification time.

9. Line 321: I guess "transformed data" means the data used as input
   for computing the hash of a dsig:Reference?

10. Line 326: Reason codes should be elaborated in more detail.

11. Line 350ff: Additional query feature: Which signing keys can be
    used by the requestor?

12. Line 356f: Is it useful for the requester to know which sig algs
    and transforms the service supports for signature verification?
    What can the requester decide upon this information? I. e. isn't
    it sufficient to send a signature to the service and wait how
    the service responds (possibly with an error "do not support
    sig alg xy"?

13. Line 364: Profiling is fine, but I think there should be minimum
    requirements to be fulfilled by each DSS.

14. Some requirements I listed in my mail [2] have not been considered
    in the draft. Could you please either add the requirements or 
    provide the motivation for not considering them?
    - req 2.1.2
    - req 2.2.2
 
Regards, Gregor



---
[1] http://lists.oasis-open.org/archives/dss/200212/msg00000.html
[2] http://lists.oasis-open.org/archives/dss/200301/msg00016.html

> -----Original Message-----
> From: robert.zuccherato@entrust.com 
> [mailto:robert.zuccherato@entrust.com] 
> Sent: Monday, March 24, 2003 10:08 PM
> To: dss@lists.oasis-open.org
> Subject: [dss] Groups - dss-requirements-1.0-draft-02.doc uploaded
> 
> 
> The document dss-requirements-1.0-draft-02.doc has been 
> submitted by Robert Zuccherato 
> (robert.zuccherato@entrust.com) to the Digital Signature 
> Services TC document repository.
> 
> Document Description:
> 
> 
> Download Document:  
> http://www.oasis-open.org/apps/org/workgroup/dss/download.php/
> 1182/dss-requirements-1.0-draft-02.doc
> 
> View Document Details:
> http://www.oasis-open.org/apps/org/workgroup/dss/document.php?
> document_id=1182
> 
> 
> PLEASE NOTE:  If the above links do not work for you, your 
> email application
> may be breaking the link into two pieces.  You may be able to 
> copy and paste
> the entire link address into the address field of your web browser.
> 
> -OASIS Open Administration
>

smime.p7s