Re: [dss] Comments on Requirements Draft

[Trevor Perrin <trevp@trevp.net>]

At 02:47 PM 3/27/2003 -0500, Robert Zuccherato wrote:

>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>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).
I'll add that.


>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.

I'll put that in, since that seems a good compromise, unless anyone wants 
to keep discussing it.


>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.

I think on the call we talked about "asynchronous" protocol runs, where the 
client sends a request (maybe in email or something), then a human reviews 
it, and then several hours later the request is approved and a signed 
document is returned.

In that case signing time and request time could be substantially 
different.  Do we want to support that case?



>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.

I think most public-key signature algorithms (PKCS v1.5, PSS) incorporate 
an OID of the hash algorithm in the data they sign with the private key, or 
do something similar.  If they don't there's a rollback attack where, even 
though you signed with SHA1, if I can find pre-images on MD4 or something, 
then I can make a forgery and tell the recipient the message was MD4-hashed 
(10.1.2 Note 1 in RFC 2313).

So if a DSS service doesn't know the OID of your hash algorithm, it might 
not be able to sign it.  I'll add a sentence to explain the rationale.


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

So would Gregor.  But we still want indirect delivery for the to-be-signed 
data?


>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.

Okay.


>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.

So we need two timestamps/marks, in that case? - one for when the 
verification was performed, one for what time the server was verifying at?

Trevor