[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Attendance and minutes for jan 12 meeting
Please send any corrections or additions to the list, not to me. /r$ -- Rich Salz, Chief Security Architect DataPower Technology http://www.datapower.com XS40 XML Security Gateway http://www.datapower.com/products/xs40.html XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html
Format is: attendance, minutes, new AI's, old AI updates.
>Date: Monday, 12 January 2004
>Time: 12:00pm - 01:00pm Eastern Time
Voting Members
Dimitri Andivahis, Surety
Juan Carlos Cruellas, self
David Finkelstein, RSA Security
Pieter Kasselman, Baltimore
Andreas Kuehne, self
Hal Lockhart, BEA Systems
Mike McIntosh, IBM
John Messing, American Bar Association
Tim Moses, Entrust
Anthony Nadalin, IBM
Trevor Perrin, self
Nick Pope, self
John Ross, self
Rich Salz, DataPower Technology
Krishna Yellepeddy, IBM
Prospective Members
Paul Madsen, Entrust
>1. Welcome by chair (Nick Pope).
Done.
>2. Confirm Minutes Secretary (Rich Salz)
Done.
>3. Roll Call.
Details to be provided by Hal.
Numbers were 12 of 20 -- quorum achieved.
>4. Approval of Agenda
Approved by acclamation.
>5. Approval of Minutes of DSS TC Face to Face previous meeting:
>15 December 2003
>http://www.oasis-open.org/apps/org/workgroup/dss/download.php/4637/dss-minutes-15-dec-2003.txt
Approved by acclamation.
>6. Review of outstanding actions
See below.
>7. Core document. (WD-09)
>http://www.oasis-open.org/apps/org/workgroup/dss/download.php/4915/oasis-dss-1.0-core-spec-wd-09.doc
Trevor: Minor changes in most recent version -- AI
03-11-04-1, and a typo fix. Mostly stable, need to track
profiles and bindings, update references. PDF version
now available.
>8. Profiles - presentation of initial ideas
>- Timestamping
> http://www.oasis-open.org/apps/org/workgroup/dss/download.php/4919/oasis-dss-1.0-timestamping-profile-spec-wd-01.doc
Trevor: Hopefully produce template for others to use.
Have some questions, including:
+What type of timestamp to produce (RFC 3161, XML, etc);
allow multiple types, or define a specific format (X509
based?)
+What transport, security, etc., bindings are needed?
+What type of security (signed requests, authenticated errors,
etc) is needed for the protocol interactions?
Trevor will send out a summary of the issues. [NEW AI]
Nick: worth separate sections on bindings, protocols, etc.
Will send email with more details.
Juan-Carlos: If doing CMS-signatures, need to understand
relationship to RFC 3161 -- is it a competitor?
Trevor(?): This is a good reason to be generic on timestamp
format.
Nick: endorse using timestamp profile as layout template for
others.
>- XAdES
> http://www.oasis-open.org/archives/dss/200401/doc00000.doc
Juan-Carlos: short proposal with underlying thoughts.
Based on lifecycle of XAdES: creation, initial verification,
refresh/update (such as for archiving) or asking for timestamp
for validation, re-verification for (after the fact)
arbitration purposes. Profile would support all these phases.
?: Arbitration?
J-C: Yes, open archive and re-verify.
>- WS-Security profile
Nick: Frederick is interested, but was not present at the meeting
to provide update.
>- Corporate seal profile
Nick: Also of interset to legalXML. Will wait and see
to better understand their requirements, discuss with John.
Idea is to support third-party.
John: I thought we also wanted to support an entity acting
on its own behalf. And take on legal obligation as a result.
Nick: This is more than just integrity.
John: yes.
Nick: This might be same mechanism, but meaning behind it
might be different.
John: Need to make sure person acting as the signer is authorized,
to make sure it's not "hijacked." Different from tamper-proof seal.
Nick: This might be a separate profile.
>- Code-signing profile
Peter: Mapping elements from core to code-signing world.
Want to keep it generic, than in appendices have mappings to
specific code-signing formats. Alternative is to have separate
documents. A reason for this is that there are a large number
of code signing formats, so separate documents might be easier
to add support. More details to be posted to the list.
Nick: Generic profiles, with sub-profiles?
Peter: Yes. Here's the generic, and then here's how to
apply the generic to CAB files, etc. Need to think how to
enable many types of mappings. I will send to the list to
get the ball rolling.
>- EPM Profile
Nick: Steve expressed interest on the list in submitting
something; they need to get the right resources involved.
Juan-Carlos: We should take an action to ping them via
email. [NEW AI on the chairs]
Discussion on policy-wise
Paul: Core allows for many options
Paul: Server is responsible for determine signature
type, etc.
Nick: So this is for a dumb client?
Paul: Dumb, or underprivileged.
>9. Profiles - next steps
>- Tasks on specific profiles
>- Co-ordination tasks
Nick: How to organize profiling, find common
structure, ensure alignment with the core?
Juan-Carlos: A general coordinator would need to assess
alignment of profiles with core. For example, XML constructs
being re-used from the core. In XAdES we came up with
a list of tasks on how to accomplish the profile.
Rich: so it's like a "style manager." I think it's a
very good thing.
Nick: think about taking on this role. Chairs will discuss.
Juan-Carlos: what about a task list? We [chairs] should discuss
to see which of the tasks make sense to circulate for others
doing profiles.
Nick: Some, such as time-stamping, are very straightforward.
Some will need more work.
Juan-Carlos: Yes. Having a task list makes it easier to
track progress of profiles when we better understand what they
need to specify.
Nick: Really want a short document from all profiles for next
meeting so that we can determine what the next steps should be.
Trevor: Authors should look at TS profile, which is pretty
simple, to see how appropriate the structure is to their
profiles.
?: You mean the XAdES outline?
Nick: That's the minimum; if you can get into more detail,
that's fine. But do it in time for review at next meeting.
>10. Any other business
None.
>11. Confirm next conference call: 26th Jan 04
Confirmed.
>12. Close
Done.
>--
New action items:
04-01-12-01 Trevor: Send out summary of the issues discovered
while developing the timestamping profile.
04-01-12-02 Juan-Carlos/Nick: Ping EPM folks via email.
>Outstanding Actions:
>03-11-04-1 / 03-12-15-1: Trevor is to add a note in the core document
>to indicate that profiles must explain the semantics of the claimed
>identity element.
Done.
>03-11-17-3 Juan-Carlos has circulated a proposal: Potential
>contents of additional details present in the verification response -
>JC/Trevor to continue discussion on potential contens for additional
>details
Their discussions continuing; still open.
>03-11-17-4. John Messing to ask the legalXML group meeting if they
>want to submit a profile for DSS and if they want to will (sic) it to be
>defined as a formal signature.
Issue raised; they have no interest. They are considering
a "digital lock" which is like other DigSig profiles.
Likely: hash will be minimal, but sig will be "best practice."
Formal issue closed, but John will track with they're doing.
>03-12-15-2: Juan-Carlos and Nick are to request expressions of
>interest in developing profiles for the next meeting.
Done. Some interest expressed; see below.
>03-12-15-3: All who are interested in developing a profile are to
>provide a discussion of the proposed characteristics of the profile
>by the next meeting.
Paul Madsen policy-wise server profile: how to use DSS
protocol when all hash mechanism, etc., issues are handled by
server. Paul to send a note to the list.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]