OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: [dss] Draft Minutes for DSS TC Meeting Monday, January 27, 2003


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

Minutes for the January 27, 2003 Meeting of the DSS TC
----------------------------------------------------------
DSS TC 1/27/03
Attendees
Members:
Carlisle Adams, Entrust
Steve Anderson, OpenNetwork Technologies
Dimitri Andivahis, Surety
Jeff Bohren , OpenNetwork Technologies
Phillip Hallam-Baker, Verisign
Frederick Hirsch, Nokia Mobile Phones
Merlin Hughes, Baltimore
Gregor Karlinger, Austrian Federal Ministry for Public Services and Sports
Pieter Kasselman, Baltimore
Andreas Kuehne, self
Ram Austryjak Moskovitz, Verisign
Nick Pope, self
John Ross, self
Rich Salz, DataPower Technology
Manoj K. Srivastava, Infomosaic Corporation
Kate Wang, IONA
Gideon Yuval, Microsoft
Robert Zuccherato, Entrust
Prospective Members:
Burt Kaliski, RSA Security
John Messing, self
Simeon Sheye, Cryptomathic A/S
The Chair reported that a quorum was reached The minutes of the meeting (2d draft) of January 13, 2003 were moved, seconded, unanimously approved.

Input documents
A use case for plug and play certificates in the form of an IETF draft from Anders Lundgren had been distributed to the list. <http://lists.oasis-open.org/archives/dss/200301/msg00020.html>. The proposal concerned adding extensions to X-509 certificates to better support web services. A CA can specify a namespace by a URI stated within a certificate; CA's can share common namespaces between them. Limitations upon a CA's offering of types of certificates could also be included in an extension. There was a means for a flexible identification of permanent identifiers. A powerpoint presentation was also included.

Other Use cases.
Pieter Kasselman introduced another use case. A client who has received digital signature but has no trust relationship with the signer can use a DSS server with which it does have a relationship to validate the signature. The DSS verifies the signature and the response may be more than just a valid/invalid signature response. A pointer to one or more policies used to validate the signature can also be provided. Pieter broached the subject of including signature generation as well. Burt

Burt Kaliski put forward ideas about authentication.
Merlin had proposed enabling nonXML DSS signature services. <http://lists.oasis-open.org/archives/dss/200301/msg00036.html>.

Manoj asked if these would be in the format of an XML DSIG document. Merlin replied affirmatively, but noted there could also be another SMIME namespace indicated for nonXML documents. There was general support for having non-XML data signed at the server as well as XML documents.

Gregor Karlinger had raised the issue of signing XML structures themselves on the list. <http://lists.oasis-open.org/archives/dss/200301/msg00034.html>. The issue of presentation signing vs. pure XML structures generated discussion about legal requirements and nuances, the ability to fashion templates that would enable signing once and still segregating out XML structures without having to rely upon a server to make the association between presentation and structure; whether such a proposal would necessitate additional server-client round-trips; and whether the proposal could reduce Internet fraud. This led to a general discussion that the TC should probably look into the issue of DSS Signing templates and whether to include them in the work of the TC.

John Messing stated that he was awaiting communications that would enable submission of use cases consistently with the Oasis IP policies and expected to submit them within a week or so.

Scheduling.
It was decided to leave the date somewhat flexible for use cases but to proceed with what was already in hand in order to develop an understanding of the requirements and the work to be performed by the TC. The subcommittee would begin work on managing the use cases and making recommendations to the TC from this work.

The following schedule and general timeline for achieving our objectives was proposed:
Use Case subcommittee to collect use cases and requirements and make recommendations for February 10th meeting. TC to decide on which inputs to accept as starting points by March 10th meeting. Editors to produce first drafts by April 7th meeting. TC to approve Committee Specifications by the end of the year (2003).

The proposal was moved, second and adopted. It was agreed to put the schedule up on the website.
The Use Case subcommittee was invited to use the TC list and private email for its work. It will report to the TC at the next meeting on the use cases it has collected and its progress towards developing requirements from them.

Entrust will sponsor the next TC telephonic meeting on Feb. 10, noon EST.




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC