[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Draft Minutes May 5, 2003
Hello All: Here are the draft minutes: Date: Monday, May 5, 2003, 12:00-1:00 pm Eastern time. 1. Welcome by chair. -Approve agenda. A new agenda item 6a was added. See below. 2. Roll call. Voting Members Carlisle Adams, Entrust Steve Anderson, OpenNetwork Technologies Dimitri Andivahis, Surety Juan Carlos Cruellas, self Frederick Hirsch, Nokia Mobile Phones Merlin Hughes, Baltimore Burt Kaliski, RSA Security Andreas Kuehne, self Hal Lockhart, BEA Systems John Messing, self Anthony Nadalin, IBM Trevor Perrin, self Nick Pope, self Rich Salz, DataPower Technology Simeon Sheye, Cryptomathic A/S Krishna Yellepeddy, IBM Gideon Yuval, Microsoft Robert Zuccherato, Entrust 3. Approve minutes of previous meeting. -Minutes of DSS TC Meeting April 7, 2003 available at http://www.oasis-open.org/apps/org/workgroup/dss/download.php/1462/meeting%2040703%20minutes.txt The minutes were approved by consensus. 4. Linking-Based Timestamping Protocols (Continued from last meeting) -As a general principle, the standard of the TC should be broad enough include to support for existing use cases and forseeable future use cases, without however making additional formal declarations that duplicate existing standards. The timestamping issue is one example of this principle. 5. XKMS Last Call Draft -The XKMS WG requested comments on their Last Call Working Draft. After discussion on the list, Robert posted a suggested response that indicated it might be nice to query a DSS client's key and receive information on the DSS server to which the client has delegated signatures. Robert asked: Are we okay with this response? Krishna suggested as a refinement adding to the request element a parameter for the RespondWith element.After discussion, Krishna agreed to provide comments to the list in time for Robert to submit to XKMS list before 23 May. 6. Identifying Requester -There had been quite a bit of discussion on methods for the DSS server to identify the signature requester. Note was taken that in his latest requirements draft Trevor suggested that we leave the question entirely to higher-level standards (See http://lists.oasis-open.org/archives/dss/200304/msg00123.html.) Robert had suggested a compromise position in which we specify an extensible list and leave it up to higher-level standards how to deal with them. (See http://lists.oasis-open.org/archives/dss/200305/msg00005.html.) During the meeting, the following were suggested as possible candidates for such a list: name of requestor authentication information other information to be specified whether this was to be part of the core protocol Mention was made by Fred Hirsh of an authentication level context in the Liberty Alliance, which could include the kind of information associated with a registration authority of a CA. It also dealt with security of key storage. There was consensus that more discussion on the list was needed. Nick Pope indicated he wanted to review the Liberty Alliance material and consult with others, including John Messing before the TC reached a conclusion. 6a. Nick and Juan Carlos submission. This involved a paper that Juan Carlos had submitted to the TC on May 5. See http://lists.oasis-open.org/archives/dss/200305/msg00015.html In discussing this item it was agreed that many of the subjects related to agenda item 6 and were useful to help resolve differences but While agreeing generally, Juan Carlos and Nick also emphasized that the document went beyond just Signer Identification. One proposal is to make signature policy NOT REQUIRED but NORMATIVE. Would this be part of the core protocol or a profile? Discussion on the list was to follow. Juan Carlos agreed to annotate the new submission with references to the paragraph numbers of the emerging requirements document to show how the individual parts of latest work product could benefit from the new submission. 7. Next Steps -Robert undertook responsibility to verify IP declarations on the various protocols as a step preliminary to identifying probable candidates for drafting the protocol itself. 8. Next meeting two weeks 9. Close.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]