Re: [dss] Proposal for discussing f2f meeting agenda

[Trevor Perrin <trevp@trevp.net>]

At 05:15 PM 7/14/2003 +0200, Juan Carlos Cruellas wrote:

>Dear all,
>
>Please find below a rough agenda proposal for the f2f meeting
>that Nick and myself have sketched today.
>We propose to quickly comment it during our conf call....
>We have identified four main"headings" (identified by capital
>letters) and certain issues below each "heading", identified by
>numbers..

A lot of these issues below are kinda covered by the requirements doc.  I 
wonder if we could try to finalize the doc on these points, by discussions 
on list, then ratify the doc at the beginning of the f2f and move on to 
actual protocol design?  I.e., try to put some of these issues behind us 
and get into nuts and bolts?


>=======================================
>
>A) OUTSTANDING ISSUES (Day 1)
>
>1. Clarification of what  will be included in the Core will and what
>is defined by a profile.

The latest requirements doc tries to be clear on what goes in the 
"Protocols and Core Elements" doc, and what profiles are.  In paticular 3.1 
and 3.10.  Do these work for people?


>2. Signature and Time-stamp: relationship
>It should be agreed whether which option we choose:
>different protocols, or one protocol using "generalization"
>as suggested by Trevor.

I think Ed and I have converged that the Signing and Timestamping protocols 
will have basically the same contents, but it may be worthwile to 
differentiate them via naming, and this is an issue that will be looked at 
in actual protocol design.


>3. Management of optionality and extensibility.
>This issue is related with how the different options should
>be managed by the protocol.
>IF tier approach is selected:
>         1.Defining these tiers and
>         2. Identifying their specific features and components.
>Although it could be selected another one...

Optionality and extensibility is a good thing to discuss, and I think Ed 
will send the list some text about this.  As for tiers, I kinda think if we 
just describe a generic protocol with optional elements, then profiles of 
this protocol can easily enough constrain this optionality, by mandating or 
disallowing certain options, and and that's all we need.



>4. Signature and verification practices  and policies.
>A good number of issues have been identified as candidates
>to be defined by "policy" or "practice" of the service. It would be
>worth to spend some time to try to clarify the issue.

this might be stuff outside the scope of the protocol per se, like 
non-repudiation, archiving requirements, etc..


>  5. Requestor identity. This issue deserved
>  lots of discussions trhough the list...We should discuss on:
>         .whether the different ways identified in the requirements doc.
>               cover the most  relevant possibilities.
>         .dealing with potential future different ways of providing it.
>         .dealing with authentication (see requirements doc)

I think if we start off doing the ways mentioned in the doc, and leave it 
extensible, that's good enough for a start, and then other people can 
extend it if necessary.




>6. 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...
>
>
>7. 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.

I put these in (3.7.7).

>         . 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?)

yeah, these latter are tough.  There's some text in 3.7.6.


>B) TABLE OF CONTENT FOR CORE DOCUMENT (DAY 2 am)
>
>C) TOPICS TO BE ADDRESSED IN PROFILE (DAY 2 pm TO 3PM)

Are these adequately covered by requirements doc?

Trevor