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] | [List Home]

Subject: Minutes of 8 September meeting

Following  are the minutes for the 9/8/2003 meeting. Please send corrections and comments  to me.
My apologies in advance for any  transcription errors.

DRAFT MINUTES; please send corrections to  kyellepe@us.ibm.com

DSS TC  meeting, 8 September 2003.

         Voting Members
         Juan Carlos Cruellas, self
        David Finkelstein, RSA Security  
        Steve Gray,  Universal Postal Union                 
         Frederick Hirsch, Nokia Mobile Phones
        Burt Kaliski, RSA Security
        Pieter Kasselman,  Baltimore
         Andreas Kuehne, self
       John Messing, ABA
        Tim Moses, Entrust
        Trevor Perrin, self
        Nick Pope, self
        Rich Salz, DataPower  Technology
         Ed Shallow, Universal Postal Union
        Krishna Yellepeddy, IBM

        We had  quorum.
Minutes of  DSS TC phone conferences 11 & 25 Aug approved

Existing Action items:
Action 17: Nick to send text to list acknowledging that the XKMS  response meets our needs; then will forward to XKMS group.  
        Since no one had any problems with the  response Nick drafted, he
        will forward  his response  to the XKMS group.

Requirements Document
         Trevor observed that the draft is vague with respect to  compound protocols.
         Nick suggested putting the compound protocol details in the core  document.
         Krishna observed that the section on requester identity should describe  
        that names in  X.500 certificates could be expressed in the subject name
        field, or the subject  alternative extension field, and that this needs to get
        factored into the kind of  names that a DSS provider could handle (see action 20 below).
        Nick suggested that these  different naming options be accounted for in the
        schema document.  
         Requirements draft V12 was approved.

Core Document
         There were a number of submissions to the list on this subject  and several
           Nick said that compound operations & processing options came  from Ed Shallow
         during the face to face meeting. This was based on Ed's earlier work at  UPU.
        Ed  submitted concept of processing options, Tim then provided details  about
         this. Tim, during the call, said that we may be talking about a small  number
        of  compound operations, e.g., two requests - doStuff and checkStuff.   Actual
         stuff would be elaborated in processing options document. We can think  of processing
         options with relatively simple policy expressions.  This was  followed by detailed
         discussion by several members ( including Tim, Juan Carlos,  Frederick, Nick, Ed).
         Frederick asked hadn't we talked about atomic operations that we  could define
         upfront ?  Tim's suggestions for an open container in which we can  put any policy
         expression came up for discussion. Juan Carlos expressed concern about  putting
         operations and policy statements together, and that trying to establish an  
         equivalence between them would be strange. Members agreed that this discussion  
        would be  continued later on the list.
         Everyone agreed that the concept of processing options  was the starting point.
                 Next discussion was on verify counter-sign  and whether to have a separate operation
        called VerifySign.  Nick said that it  was worth having VerifySign as a separate operation.
         Trevor supported  this. John asked for a clarification - is the server signing after  
        verifying ? The  answer was,yes think of it as the server augmenting the previous  
        signature.  Another example was that verifying and signing would be like notarizing.  
        John  Messing then talked about how Federal and state courts are moving fast  towards
         adopting an approach for electronic filing and signing and verification  of
         documents. The approach is based on taking the hash of the document checked in  and associated
         database operation details that John described.  John will write  this up and send to the
         DSS-mailing list (listed as Action 21 below) . He expressed concern that the DSS architecture  could not
         handle this electronic filing scenario. This observation was made:What John is  describing
         in the context of  electronic filing for courts is strictly not a digital  signature.
        Juan Carlos  suggested we stick to the outcome of f2f meeting regarding schema.  General
         structure agreed was - document to be signed, the claimed id of requestor,  key
        that  requestor wanted service to use, different option types that should  
        be included in  the reply. Juan Carlos said he has reviewed Trevor's schema and that  
        we can  accommodate mechanisms Trevor has described in the schema.
        Trevor said he'd be  comfortable having individuals work on this schema
        separately, without  adopting one or other version as a working
        draft for now.  Nick stated that it  was important to get the signed
         structure sorted soon since operations depended on this.  
                 Juan Carlos and Trevor both volunteered to add more   text to the
         XML schemas they have proposed so far. Ed Shallow said that Juan  Carlos
        had  already done a good job with the descriptive text for the XML schema,  
        but more  description would not hurt. After lengthy discussion among the members  in
        which  options such as holding a meeting next Monday to resolve this issue  
        were proposed, it  was agreed that Juan Carlos and Trevor would work on the
        schema issues together and  reach an agreement. Any unresolved issues will be discussed
        by the entire TC.    Juan Carlos and Trevor agreed that they would post their discussion to the  list.

        Juan Carlos said we have  the initial proposal for validating request.  Usage
        of different elements has  been elaborated.  Need to work on processing options elements.  

        Tim said he was not aware  of issues on this and that the approach was sound.

Implicit parameters:  
        As we were out of  time, this issue to be discussed at our next meeting.

Object naming
        Nick asked if everyone was OK with the  object naming guidelines.
         Since no one had any problems, Nick asked when do we send  this to the
         other chairs ? Tim responded that we don't and that TAB (  technical
         advisory board) will handle  sending to the other chairs.  
        Trevor asked  whether to update our documents based on this convention.
        Nick's response was to do  the renaming for the next version of each

Action  20. Krishna Yellepeddy to send a note to list regarding Requestor Identity  
(section 3.3.2) in DSS Use Case Requirements  Analysis document. He will
elaborate  on the different kinds of names from X.509 certificate that a
DSS would need to handle.

Action 21:  John  Messing to send a note to list describing   the approach for electronic
 filing and signing and verification  of documents  to be adopted by Federal and state courts.


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