RE: [dss] Draft Minutes for DSS TC Meeting Monday, January 13, 2003

[Nick Pope <pope@secstan.com>]

Title: Draft Minutes for DSS TC Meeting Monday, January 13, 2003

Can I suggest clarification of what I said as below.  The current discussion mixes long term, 30 years with requirements for the ability to verify the signature a short period, say a few days / weeks, after the signature where the problems are more tractable using , for example, time-stamping.

 

......

  - Carlisle Adams:  discussed the use cases he submitted
 - Nick Pope:  should corporate seal be non-repudiable? 
[Nick Pope] 

I suggest that "long term verificiation" is replaced by "verification some time later". as updated below:

 

 Should it allow a for verification[Nick Pope]  some time later ?  Nick suggests that corporate seal could be split into two pieces:  immediate verification, and verification[Nick Pope]  after some time .  For SOAP signing, this might only be immediate verification (i.e., simply authenticate requester).  It is possible that you could save the SOAP message for a long time, but it is more likely that you would just keep the signed content (not the entire SOAP message).  In general (today), by the time the application receives the data, the SOAP envelope is gone.

 - Manoj:  SOAP signature may not be on the whole payload, but only on relevant pieces, and those are the pieces that get kept.

 - Nick:  so again there are two variations:  sign whole payload, and sign pieces according to a particular template.
 - Nick:  for the identified requester use case, there is again immediate authentication and signatures[Nick Pope]  after some time .  [Nick Pope] In the extreme case it may be necessary to keep signatures verifiable for 30 years or more[Nick Pope]  although such long period may be more difficult to address .  Carlisle:  does this have implications for the protocol itself?  Nick:  yes.  If the requester knows that this signature needs to be verifiable for a long time, it may indicate in the request that it wants all the relevant revocation information, etc., returned in the response.

 - Carlisle:  notes that Hal Lockhart also posted a note on this topic, but Hal is not on the call at the moment, so perhaps discussion of his note should be deferred until the next call

 - Burt Kaliski asked about requirements for user authentication:  does the user authenticate separately to the network (or to the DSS server)?  If so, how does this work?

 - Robert suggested that this should be marked down as one of our requirements.  Burt will write this up and submit it to the list.

 - Krishna will send out a first cut at a requirements list as soon as possible after this call.
 - cut-off date for submission of use cases?  January 27th is the current date.  Consensus that this should be re-assessed on the call on the 27th to see if the date should be extended.

 - requirements and use cases will proceed simultaneously.
 - subcommittee will meet at the end of the month, then begin to work on prioritizations, etc.  They hope to have something to present to the whole TC by mid-February.

 - Krishna:  are there other mailing lists that can be targeted (i.e., to solicit for use cases and requirements)?  Perhaps XML Signature?  Robert will send a note to that list asking for submissions

 
Next Meeting Sponsor:  RSA Security (Burt Kaliski will send details to the list)
 
No other business -- adjourn.

-----Original Message-----
From: Robert Zuccherato [mailto:robert.zuccherato@entrust.com]
Sent: Friday, January 10, 2003 11:06 AM
To: 'DSS TC'
Subject: [dss] Agenda for DSS TC Meeting Monday, January 13, 2003

Agenda for Digital Signature Services Technical Committee Meeting

Date:  Monday, January 13, 2003, 12:00-1:00 pm Eastern time.
Dial-In Information:  +1 408 902 7870 Meeting ID:  123456

1.  Welcome by chair.
        -Approve agenda.
2.  Roll call.
3.  Approve minutes of previous meeting.
        -3rd Draft of Minutes for December 16, 2002 Meeting sent out
         January 10, 2003.
4.  Input documents.
        -EML (Election Mark-up Language) Appendix C: The Timestamp Schema
         John Ross
        -Towards an XML Format for Time-Stamps
         Gregor Karlinger
5.  Use Cases.
        -We formed a Use Case Sub-committee and issued a "Call for Use Cases"
         on December 16.  Thus far we have only had one submission in response
         to our call.  I would like to encourage submission of use cases as
         we will use the submitted use cases to produce requirements, which
         will be used to decide among the various submission that have been
         made.
        -Entrust use case submission
         Carlisle Adams
6.  Any other business.
7.  Close.