[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] Draft minutes
Tim, Thanks for this. I identified the following areas where I suggest changes are made. - Move minutes to front & make other items to end. - Add roll call - Add approval of minutes of last meeting - Organised discussion of requirements around that agenda item - Changed title of the following requirements discussion to match agenda - The conclusion on the DSS support for CMS etc drafted by Frederick - Added conclusions about requirements document - Added plans for input to core from various persons - Updated patent discussion as the current minutes only reflect statements made at last DSS meeting, and need to update DSS website not mentioned. I attach the revised minutes. Nick > -----Original Message----- > From: Tim Moses [mailto:tim.moses@entrust.com] > Sent: 28 July 2003 21:38 > To: 'DSS' > Subject: [dss] Draft minutes > > > Colleagues - Please find below, draft minutes of the first DSS > face-to-face. > Please post corrections to the list for discussion during the > next telecon. > Thanks a lot. All the best. Tim. > > > > Minutes > OASIS Digital Signature Services > Face-to-face number 1, 24-25 July 2003 > Location: Burlington, MA > > Actions: > > The following actions were established during the course of the meeting. > > 1. Update requirements document by August 1st (Trevor). > > 2. Produce initial schema for the sign/verify and timestamp operations by > 5th Aug. (Trevor will work with Juan-Carlos). > > 3. Post a discussion on compound operations to the list (Ed). > > 4. Produce analysis of the submitted materials on timestamp token syntax. > If possible, provide draft text to Trevor by 1st Aug (Tim). > > 5. Send references to timestamp token syntax to Tim. (Juan-Carlos) - > complete > > 6. Send Overview text to Trevor by 1st Aug. Mention bindings issues > (Frederick). > > 7. Produce initial text on the WS-Security profile (Frederick). > > 8. Update intellectual property page (Nick/Juan-Carlos). > Currently, the DSS > page has two declarations on IPR. > > 10. Check with John Messing regarding an author for the notary service > profile (Nick). > > 11. Check whether there is a need for a profile for the German > signature law > (Andreas). > > Issues > > The following issues were identified > > 1. If the server does not support one or more of the property values > requested by the client, should it complete the signature? The topic was > discussed at the meeting, and it was decided that unless the server can do > exactly what it is asked, it will return an error. > > 2. What mechanisms for identifying target nodes should we > support? E.g. id > attributes, XPath expressions, etc.. > > Minutes of the meeting > > 1. Quorum was achieved. > > 2. The agenda was reviewed. > > The following items were added to the agenda. > 1. Discussion of signature formats (such things as PKCS#7, PGP, > EDIFACT, in addition to XML digital signature). > 2. Discussion of bindings and WSDL. > 3. Discussion of patents. > The modified agenda was agreed. > > 3. Content of the core document and profiles > > A structure for the core document was decided. It will contain two main > sections. One will describe the protocol and its extensibility > points. The > other will define the token structure, including generally useful > attributes > with global definitions and extensibility points. > > Profile documents will specify the functions performed by the service. > > 4. Token syntax > > The question of the syntax of the timestamp token was discussed. It was > suggested that the <Manifest> element is probably the right place > to put the > document digest, as opposed to the <References> element, because the > verifier won't be able to verify the hash when the pre-image is not > available. > > It was agreed that a DSS-created signature must be verifiable by > a standard > DSS implementation and vice-versa. > > It was agreed that the group will have to define the syntax of a timestamp > token (TST) element, similar to the RFC 3161 token syntax definition. The > time element definition in the TST should be re-useable as a time-mark > element. > > If the document is both signed and time-stamped, then there > probably will be > two separate digests and signatures (one for each). On the other hand, if > it is a time-marked document, there may be only one digest and signature. > > Hal pointed out that the semantics of messages in each form must be clear: > no multiple semantics for the same syntax. > > XAdES defines a location for time in its signature syntax definition. XML > Dsig does not. > > 5. Protocol syntax > > The question of support for legacy signature formats was raised. It was > suggested that this should have no impact on the protocol. On the other > hand, Hal suggested that some requests may have to be tailored to the > requirements of the requested signature format. > > The motivation behind verifying at a server was discussed. Following > discussion, it was confirmed that there is value to this. > > The question of how to express a request for a compound operation (e.g. > signature AND timestamp) was raised. Simplicity for the client must be > paramount. > > The question of whether the service should be stateful or stateless was > raised. We decided to proceed on the basis of a stateless model. > > 5.1 Update operation > > One compound operation is "update". This "refreshes" a timestamp or > signature by verifying the original and applying a new timestamp or > signature, possibly adding new information. > > There was discussion of the best way to implement composability and > extensibility. It was decided to consider concrete schema > proposals to help > us compare the available approaches. However, there appears to > be a need to > define four operations: sign, timestamp, verify and compound. > > It was suggested that "update" could be a variant of the verify operation. > Any information added by the update operation can be returned in a verify > response. > > Frederick suggests that update should be a separate operation, > not a variant > of one of the other operations. > > It was also suggested that update is a more natural variant of the sign > operation. > > 5.2 Requestor identity > > The service requestor is identified in the operation response and > derived by > the server, based on available authentication information. The server may > have fewer keys than there are requestors. Therefore, it is important to > have a way to identify the requestor in the response. Nick > pointed out that > the requestor name in Section 3.3.2 of the use-cases and requirements > document may be a role; it is not necessarily a unique name. > > The discussion turned to the applicability of the Liberty Alliance > authentication context in relation to the requestor identity. > This would be > an optional attribute of the signature. > > The requestor should be able to stipulate which requestor identity to use. > The requestor identity could additionally be used to select the > signing key. > However, it was felt that it is better to keep these two data items > separate. > > 5.3 Policy > > There was discussion of policies and how they would be associated with > services and operations. The policy discussed here is what ETSI > would call > a signature policy. > > Policies can be implicit in the identity of the end-point to which the > request is sent. Static aspects of policy can be expressed in application > profiles. Then there are options within a profile. For the > time-being, we > will just allow policy to be represented by an identifier; we > won't specify > any elements of policy. If the policy is implied by the service URI, then > the policy indicator does not have to be used. However, it is > important to > put the policy indicator in the response. All of the policy features are > optional. > > Policies may be published out of band (e.g. posted at an HTTP URL). > > In the case of the verify operation, if the request does not contain a > signature policy indicator, then the server may indicate which signature > policy it used. According to the ETSI signature policy model, signatures > must be created and verified under the same policy. > > There was some discussion of "reports". I.e. reporting on the status of > each step in the processing of a request. There was no definite > conclusion. > > The question of WYSIWYS was discussed. It was concluded that this only > applies to human interactions. > > 5.4 Metadata > > Service capabilities should be published in a metadata service; this will > not be an operation specified by DSS. > > It was asked whether we need to provide the document schema in > order for the > signer to find the nodes that it has to sign. What happens in the case > where there are no id attributes in the document? > > The verify operation will simply check if the document signature is valid, > without stipulating which nodes should have been protected. It > is a design > aim that you shouldn't have to have the document schema in order to sign, > either using id attributes or XPath expressions. > > In some cases, the service may not be able to return the signature > immediately. However, notification is complicated to implement. > So, it was > decided to provide an indication mechanism, but not to define the protocol > in the current version. > > 6. Schema > > The EPM submission has some of the characteristics required for the DSS > protocol. However, it is focused on PKCS#7 signatures. It doesn't have > some of the features that have been identified for DSS. > > The group considered one operation: the sign request and started to flesh > out the syntax. > > It was decided to import ETSI syntax definitions where appropriate. > > Operations have a range of options associated with them. The protocol > allows for "properties" to be requested. The question arose as to whether > all options can be modeled as properties. Options include such things as: > the intended audience, placement of the resulting signature > (detached/enveloped/enveloping), supporting information (that is returned, > but is not part of the signature), additional processing options, > signature > policy indicator, etc.. A signed property could be used to request the > inclusion of a timestamp in the response. It was decided to > proceed on the > assumption that the properties model is adequate for expressing all the > operation options. > > User data may include such things as: transforms and selection of the data > target, > > 6.1 Signature response > > There was discussion of whether we should have a WS-Security profile for > signing/verifying a WS-Security header. This will be added to the list of > profiles to be addressed. > > There was some discussion about the need to pass the document to > the service > and to return it, in the case that an enveloped signature is > requested. The > issue is one of latency due to serialization of the document in both > directions. If the document is not returned, the client would not have to > apply the canonicalization chosen by the service. It was decided that the > client should be required to use the detached signature option if > they want > to avoid having the document returned to them. > > The question of correlating requests and responses was raised. It was > decided to include an optional request id. > > 7. DSS profiles > > Application profiles should define some processing rules, in addition to > signature format, bindings, additional type definitions, etc.. Ones > identified so far include: XAdES (Juan-Carlos), CMS (Trevor), EPM (Steve), > WS-Security (Frederick, Hal, Tim), code-signing JARs (Trevor), S/MIME > (Trevor), notary service. > > Extension points must be incorporated into the schema. > > 8. Planning > > Trevor was appointed editor for the core document. > > The group worked on the outline of the core document. There was > discussion > on how to represent schema (i.e. which convention to follow). > > 9. Patents > > Several patent applications have been brought to the attention of > the group > by Secstan, Zolera and John Messing. > > On the topic of the Zolera patent, Rich Salz will provide a contact. > > 10. Work plan > > 5th August 2003, first draft of the core specification posted to the list. > 21st December 2003, Committee Spec. of the core specification and at least > one binding (SOAP). > June 2004, OASIS standard > 31st March 2004, XAdES profile > 31st March 2004, EPM profile > 31st March 2004, Web-services profile > > 11. Miscellaneous > > The group agreed that at some point in the future, it will notify > the S/MIME > group about this activity. > > Steve mentioned that UPU has retained a consultant to investigate whether > the EPM specification conforms with the EU directive on electronic > signature. The results may be made available to this group. > > The meeting adjourned 2:20pm on 25th July. > > ----------------------------------------------------------------- > Tim Moses > 613.270.3183 > > You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_workgroup.php
Minutes OASIS Digital Signature Services Face-to-face number 1, 24-25 July 2003 Location: Burlington, MA Minutes of the meeting 1. Roll Call Dimitri Andivahis, Surety (part of meeting by phone) Juan Carlos Cruellas, self Steve Gray, Universal Postal Union Frederick Hirsch, Nokia Mobile Phones Merlin Hughes, Baltimore (part of meeting by phone) Andreas Kuehne, self Hal Lockhart, BEA Systems Tim Moses, Entrust Trevor Perrin, self Nick Pope, self Ed Shallow, Universal Postal Union Quorum was achieved. 2. The agenda was reviewed. The following items were added to the agenda. 1. Discussion of legacy signature formats (such things as PKCS#7, PGP, EDIFACT, in addition to XML digital signature). 2. Discussion of bindings and WSDL. 3. Discussion of patents. The modified agenda was agreed. 3. Approval of Minutes of Last Meeting The minutes of the previous meeting (14th July) were moved, seconded and approved unanimously by consensus. 4. Requirements The issues remaining from the requirements document were discussed and agreed as follows: 4.1 Content of the core document and profiles A structure for the core document was decided. It will contain two main sections. One will describe the protocol and its extensibility points. The other will define the token structure, including generally useful attributes with global definitions and extensibility points. Profile documents will specify the functions performed by the service. 4.2 Core & Time-stamp Token The question of the syntax of the timestamp token was discussed. It was suggested that the <Manifest> element is probably the right place to put the document digest, as opposed to the <References> element, because the verifier won't be able to verify the hash when the pre-image is not available. It was agreed that a DSS-created signature must be verifiable by a standard DSS implementation and vice-versa. It was agreed that the group will have to define the syntax of a timestamp token (TST) element, similar to the RFC 3161 token syntax definition. The time element definition in the TST should be re-useable as a time-mark element. If the document is both signed and time-stamped, then there probably will be two separate digests and signatures (one for each). On the other hand, if it is a time-marked document, there may be only one digest and signature. Hal pointed out that the semantics of messages in each form must be clear: no multiple semantics for the same syntax. XAdES defines a location for time in its signature syntax definition. XML Dsig does not. 4.3 Support for Legacy Signature Formats The question of support for legacy signature formats was raised. It was suggested that this should have no impact on the protocol. On the other hand, Hal suggested that some requests may have to be tailored to the requirements of the requested signature format. The motivation behind verifying at a server was discussed. Following discussion, it was confirmed that there is value to this. The question of how to express a request for a compound operation (e.g. signature AND timestamp) was raised. Simplicity for the client must be paramount. The question of whether the service should be stateful or stateless was raised. We decided to proceed on the basis of a stateless model. The conclusion on this matter is: We will focus on XML-DSIG signatures applied to XML content, due to the high acceptance and use of XML digital signatures. Deployed signature solutions such as CMS are also important and should also be supported. Given that the XML Signature protocol interface must support the variety of options such as what is signed, where signatures are placed and what processing is performed, this interface should also be powerful enough to provide an interface to servers supporting other signature formats like CMS or OpenPGP. Thus we expect to be able to use a single XML based protocol for requests and responses, allowing either XML Signature or other signature formats to be returned (as typed objects, where a non-XML signature may be a base64 encoded blob) or submitted for verification. This does not mean that the DSS work group will define ASN.1 formats to extend existing signature formats or create additional custom interfaces, but rather that the one general solution should suffice to cover the core requirements while supporting a variety of server signature implementations. As areas are identified where this is not the case, they may be added to an issues list for future consideration. 4.4 Update operation One compound operation is "update". This "refreshes" a timestamp or signature by verifying the original and applying a new timestamp or signature, possibly adding new information. There was discussion of the best way to implement composability and extensibility. It was decided to consider concrete schema proposals to help us compare the available approaches. However, there appears to be a need to define four operations: sign, timestamp, verify and compound. It was suggested that "update" could be a variant of the verify operation. Any information added by the update operation can be returned in a verify response. Frederick suggests that update should be a separate operation, not a variant of one of the other operations. It was also suggested that update is a more natural variant of the sign operation. 4.5 Requestor identity The service requestor is identified in the operation response and derived by the server, based on available authentication information. The server may have fewer keys than there are requestors. Therefore, it is important to have a way to identify the requestor in the response. Nick pointed out that the requestor name in Section 3.3.2 of the use-cases and requirements document may be a role; it is not necessarily a unique name. The discussion turned to the applicability of the Liberty Alliance authentication context in relation to the requestor identity. This would be an optional attribute of the signature. The requestor should be able to stipulate which requestor identity to use. The requestor identity could additionally be used to select the signing key. However, it was felt that it is better to keep these two data items separate. 4.6 Policy There was discussion of policies and how they would be associated with services and operations. The policy discussed here is what ETSI would call a signature policy. Policies can be implicit in the identity of the end-point to which the request is sent. Static aspects of policy can be expressed in application profiles. Then there are options within a profile. For the time-being, we will just allow policy to be represented by an identifier; we won't specify any elements of policy. If the policy is implied by the service URI, then the policy indicator does not have to be used. However, it is important to put the policy indicator in the response. All of the policy features are optional. Policies may be published out of band (e.g. posted at an HTTP URL). In the case of the verify operation, if the request does not contain a signature policy indicator, then the server may indicate which signature policy it used. According to the ETSI signature policy model, signatures must be created and verified under the same policy. There was some discussion of "reports". I.e. reporting on the status of each step in the processing of a request. There was no definite conclusion. The question of WYSIWYS was discussed. It was concluded that this only applies to human interactions. 4.7 Query a DSS service provider about it's capabilities Service capabilities should be published in a metadata service; this will not be an operation specified by DSS. It was asked whether we need to provide the document schema in order for the signer to find the nodes that it has to sign. What happens in the case where there are no id attributes in the document? The verify operation will simply check if the document signature is valid, without stipulating which nodes should have been protected. It is a design aim that you shouldn't have to have the document schema in order to sign, either using id attributes or XPath expressions. In some cases, the service may not be able to return the signature immediately. However, notification is complicated to implement. So, it was decided to provide an indication mechanism, but not to define the protocol in the current version. 4.8 Conclusions on Requirements Document The meeting agreed that all the outstanding issues on the requirements document had now been addressed. Trevor undertook to revise the requirements document to reflect the discussions with the aim to get the initial version of the requirements document agreed at the next phone meeting on 11th Aug. 5. Core Schema 5.1 Sign Request The EPM submission has some of the characteristics required for the DSS protocol. However, it is focused on PKCS#7 signatures. It doesn't have some of the features that have been identified for DSS. The group considered one operation: the sign request and started to flesh out the syntax. It was decided to import ETSI syntax definitions where appropriate. Operations have a range of options associated with them. The protocol allows for "properties" to be requested. The question arose as to whether all options can be modeled as properties. Options include such things as: the intended audience, placement of the resulting signature (detached/enveloped/enveloping), supporting information (that is returned, but is not part of the signature), additional processing options, signature policy indicator, etc.. A signed property could be used to request the inclusion of a timestamp in the response. It was decided to proceed on the assumption that the properties model is adequate for expressing all the operation options. User data may include such things as: transforms and selection of the data target, 5.2 Signed response There was discussion of whether we should have a WS-Security profile for signing/verifying a WS-Security header. This will be added to the list of profiles to be addressed. There was some discussion about the need to pass the document to the service and to return it, in the case that an enveloped signature is requested. The issue is one of latency due to serialization of the document in both directions. If the document is not returned, the client would not have to apply the canonicalization chosen by the service. It was decided that the client should be required to use the detached signature option if they want to avoid having the document returned to them. The question of correlating requests and responses was raised. It was decided to include an optional request id. 6. DSS profiles Application profiles should define some processing rules, in addition to signature format, bindings, additional type definitions, etc. Ones identified so far include: XAdES (Juan-Carlos, Nick), CMS & S/MIME(Trevor), EPM (Steve), WS-Security (Frederick, Hal, Tim), code-signing JARs (Trevor), notary service (subject to confirmation of interest by John Messing). Extension points must be incorporated into the schema. 7. Outline structure of document containing the Core Specification Trevor was appointed editor for the core document. The group worked on the outline of the core document. There was discussion on how to represent schema (i.e. which convention to follow). Juan Carlos and Trevor agreed to build on the Core Schema produced at the meeting including verify. Frederick to provide interoductory text and overview. Tim to start analysis for time-stamp schema. Ed to open discussion of compound operations on list. 8. Patents The situation regarding patents had not changed significantly from the previous DSS phone meeting. The co-chairs were asked to arrange for the IPR information on the DSS web pages to be brought up to date. 9. Work plan 5th August 2003, first draft of the core specification posted to the list. 21st December 2003, Committee Spec. of the core specification and at least one binding (SOAP). June 2004, OASIS standard 31st March 2004, XAdES profile 31st March 2004, EPM profile 31st March 2004, Web-services profile 10. Miscellaneous The group agreed that at some point in the future, it will notify the S/MIME group about this activity. Steve mentioned that UPU has retained a consultant to investigate whether the EPM specification conforms with the EU directive on electronic signature. The results may be made available to this group. The meeting adjourned 2:20pm on 25th July. -------------------------------------------------------------------- Appendix A - Actions: The following actions were established during the course of the meeting. Action 1. Update requirements document by August 1st (Trevor). Action 2. Produce initial schema for the sign/verify and timestamp operations by 5th Aug. (Trevor will work with Juan-Carlos). Action 3. Post a discussion on compound operations to the list (Ed). Action 4. Produce analysis of the submitted materials on timestamp token syntax. If possible, provide draft text to Trevor by 1st Aug (Tim). Action 5. Send references to timestamp token syntax to Tim. (Juan-Carlos) - complete Action 6. Send Overview text to Trevor by 1st Aug. Mention bindings issues (Frederick). Action 7. Produce initial text on the WS-Security profile (Frederick). Action 8. Update intellectual property page (Nick/Juan-Carlos). Currently, the DSS page has two declarations on IPR. Action 10. Check with John Messing regarding an author for the notary service profile (Nick). Action 11. Check whether there is a need for a profile for the German signature law (Andreas). ------------------------------------------------------- Appendix B - Issues The following issues were identified during the meeting Issue 1. If the server does not support one or more of the property values requested by the client, should it complete the signature? The topic was discussed at the meeting, and it was decided that unless the server can do exactly what it is asked, it will return an error. Issue 2. What mechanisms for identifying target nodes should we support? E.g. id attributes, XPath expressions, etc.. ----------------------------------------------------------------- Tim Moses 613.270.3183
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]