DSS TC meeting, 8 September 2003. Attendance 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 issues. 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. Sign 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. Validate 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. Timestamping: 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 document. Actions 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.