Comments on Requirements Draft

[Robert Zuccherato <robert.zuccherato@entrust.com>]

Title: Comments on Requirements Draft

I have the following comments on the use case requirements draft. 

The document identifier for this document (according to OASIS' document identifier rules) is dss-requirements-1.0-draft-02.  The final two digits will change for the various versions of the document.

In Section 3.2.1, Requestor Identity, the idea of idea of identifying the requester's that have been authenticated is discussed.  However there is no requirement directly related to authenticating the requester.  I would suggest that we include a requirement in Section 3.3 for Requestor Authentication and that it contain the options that I proposed in http://lists.oasis-open.org/archives/dss/200301/msg00032.html. 

1)  no authentication (well, really authentication provided by other means, or another layer, for example over TLS),
2)  authentication directly to the server within the protocol (using WS-Security maybe?),
3)  authentication using an authentication authority (using SAML?),
4)  combinations of above (in order to allow the two-authentication policy).

Section 3.2.2, inclusion of the signing time within a signature is discussed.  Options here include using a "time mark" signed attribute or a "time stamp" unsigned attribute from a third party.  I think we should mention somewhere in this document, perhaps just in this section or perhaps in a new section on time stamps, that our protocol must also support obtain the "time stamp" from the 3rd party.  This protocol could be used by a client directly to obtain a timestamp on an existing signature, or by the DSS to obtain a timestamp on and inclusion in a signature that it is creating.  On the conference call on Monday we discussed possibly supporting time stamps that simply use a time mark in a conventional signature as well as having a separate token syntax for third party tokens.  I think that this is probably a good idea and this requirement for two different formats should probably be captured as well.

Question 2:  Personally I see no need to support a request time as well as a signing time.  Unless someone can come up with a use case that would support it, I would suggest that we only support signing time.

In Section 3.3.2 the statement is made that "Client-side hashing requires the client to have knowledge of which hash algorithms the server is capable of signing".  I may be missing something obvious, but why?  The client has already calculated the hash, so the DSS does not need to compute the hash again.  It can just take the resultant hash value and compute the signature.  Now, we may eventually want to produce a security requirement that the DSS should only sign using hashes that it believes are secure, but that doesn't mean that the server is not capable of signing it.

Question 4:  I would personally be comfortable with just supporting the direct delivery method.

Question 5:  I believe it would be most useful if the server should verify the signature using all of the information that it currently has available to it regarding the status of the key on the requested date.  Thus, it should answer as it should have answered then.

In Section 3.7.4 it would probably also be useful for the server to return the time in the past that it used to verify the signature if it was not simply verified at the current time.

        Robert Zuccherato.