FW: [dss] Launching discussions on objectives and extent for the face-to-face meeting

["Nick Pope" <pope@secstan.com>]

Juan Carlos,

Can I suggest that we have some discussion on how the protocol & signture
options are to be controlled, how these may be extended, relating to the
point that Tim Moses just brought up.  This brings in issues of what is in
the Core and what is in a Profile, as well as Signature / Validation /
signing policies.  Related to this I think we need to clarify what is in the
"core" and what is a "profile".

Can I suggest an additional item after Issue #1

Issue #1.5 Options and extensibility in DSS.  What is in the Core and what
is defined by a profile.  How are options controlled by Signature /
Validation / Signing policies etc.

I would also suggest that we allow time towards the end of meeting to
produce a table of contents / structure for the Core document and next steps
for filling in that structure.

Nick

> -----Original Message-----
> From: Juan Carlos Cruellas [mailto:cruellas@ac.upc.es]
> Sent: 08 July 2003 17:13
> To: dss@lists.oasis-open.org
> Subject: [dss] Launching discussions on objectives and extent for the
> face-to-face meeting
>
>
> Dear all,
>
> Below follow my first thoughts on the issues that we should
> deal with in the f2f meeting. As agreed in our last conf call
> we should open now a process that, starting in this message
> would lead to the production of the agenda, by commenting and
> ammending the content of this message.
>
> * Focus and scope of the meeting.
>
> Section 3.10 of the requirements document identifies two work products,
> namely Protocol and Core Elements and Protocol bindings and signature
> profiles.  My proposal is to try to first specify the extent of
> the CORE and
> to cover it during the meeting so that we can end it
> having enough material as to be able to produce a first version of a
> specification
> without needing big efforts.
> Now below follow some thoughts on the components of this work product.
>
>
> Issue#0. Relationship between the Timestamp protocol and the
> signature protocol.
> A number of emails have gone through the list on this issue.
> As we are facing the actual production of the DSS core protocol, it
> would be taken into account.
>
>
> Issue #1. TIER APPROACHES FOR THE REQUESTS (BOTH, SIGNING AND VERIFYING)?:
> the messages by Tim and John Messing deal with
> an important issue: how complicated should our protocol requests
> be?. Looking at the requirements document a great number of different
> possibilities appear, derived from the identified use cases.
> So, on one side we have the problem of specifying complicated protocols
> from the client point of view. On the other the fact that some of these
> complexities come from different use cases exposing
> actual requeriments on what has to be signed or verified...
> I guess that it would be possible to follow a tier-approach where we could
> start with very simple requests for the easiest cases and then define
> different tiers by adding optional components to the request so that only
> those who really need would implement them.
>
> If this approach seems OK we should then spend some time
> trying to:
> 	1.Defining these tiers and
> 	2. Identifying their specific components.
>
> And these two steps should be done on both, requests for
> signing and requests for verifying. This would be done by
> going through:
>    3.3 (Common request requirements)
>    3.4 Signing request requirements.
>    3.6 Verification Request Requirements.
>
> Issue#2. AUTHENTICATION MEANS.
> This seems a rather important issue that deserved
> lots of discussions trhough the list... We could spend some time on that
> and be
> sure that the solution taken accommodates most of the views.
>
>
> Issue#3 CORE SIGNING RESPONSE BY THE SERVER.
> So far, our requirements document identifies few requirements on
> this part of the protocol, and the ones identified seem quite obvious.
> Taking this into account it does not seem one of the most dificult
> parts of the work, although perhaps it can be influenced by the
> work on the tiers in the request...
>
>
> Issue#4. CORE VERIFICATION RESPONSE
> Here we have  a number of points that have been commented so far.
> I think that we could try to reach an agreement on whether which ones
> should be covered by the "core" protocol and be specified in our
> f2f meeting
> 	.Convenience and granularity of Individual reports.
> 	. Inclusion of cryptographic material used for verification
> (CRLS, OCSP, etc)
> 	. Inclusion of time-stamps on the former.
> 	. Inclusion of Time mark (should not a time-mark format be
> required?)
>
> Issue#5.  Work on WSDL. Assuming that we are able to progress enough then
> we could deal with initial steps dealing with the WSDL....
>
>
> COuld you send to the list any comment, proposal for addition,
> proposal for
> deletion, proposal for further details, etc that you may have?
>
> Regards
> Juan Carlos.
>
>
> You may leave a Technical Committee at any time by visiting
http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_workgroup.php