Draft minutes

[Tim Moses <tim.moses@entrust.com>]

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