Minutes May 1, 2014

For review.

-jacques

----------------------------------------

DRAFT MINUTES

OASIS WS-BRSP TC Meeting

1 May 2014, 11:00am to noon PDT

----------------------------------------

Scribe: Jacques Durand

0. Call to Order and roll call

Jacques Durand calls the meeting to order and welcomes everyone.

* Roll call:

Ram Jeyaraman

Gershon Janssen

Doug Davis

Jacques Durand

Tom Rutt

Pim Van Der Eijk

Tom Link (observer)

Excused:

Micah Hainline

Alessio Soldano

This meeting is quorate.

Agenda adopted:

1. Administrative

- Minutes March 20 meeting

- Status of updated CSDs #3 and PR #2,

- Next meeting(s) schedule.

2. Upgrading BSP11 for later versions of SHA (see minutes March 20):

- light option: keep all SHA versions on equal footing (not favoring SHA-1,

and make SHA-version an extensibility point for users to agree on)

- bold option: deprecate SHA-1 and clearly update the SHA-dependent Rxxxx to focus on SHA-2 or -256

- others?

Minutes:

1. Administrative

- Minutes March 20 meeting: approved

- TC approved modified 3 profiles CSD03 PR candidates BP12, BP20, RSP10. Jacques to resubmit to TC admin,

for 2nd PR. The test assertions are now in Annex of the profiles , part of same document (as in WS-I).

- Tentative next meeting May 29.

2. Upgrading BSP11 for later versions of SHA (see minutes March 20):

- light option 1: keep all SHA versions on equal footing (not favoring SHA-1,

and make SHA-version an extensibility point for users to agree on)

- bold option 2: deprecate SHA-1 and clearly update the SHA-dependent Rxxxx to focus on SHA-2 or -256

- jacques: requirements are affected by SHA-1:

SHOULD (SHA1): R5420, R5421

MUST (SHA1): R4212 , R5206 , R5210 , R6906 , R3072

- Pim: not in favor of the "light" option. Easiest is to remove all these SHA-1 recommendations.

- Ram: removing SHA-1 recs would mean that the profile is not really usable.

We could just add a notice of "deprecation".

- Option 2: replace SHA-1 with more recent SHA-nn recommendations, but need developer interest & input

to agree on new recommendations.

- Option 3 (lightest): put a disclaimer that the profile has not been updated to newest SHA-nn.

- Pim: Usage responsibility is of the user - seems strange to have the profile doc adding this notice (option 3).

- Pim: we'd need a security expert. We donot want to publish an upgrade until we are sure we get it right

- Jacques:Option 4: (a) define SHA-nn as an extensibility point (to be decided by users)

(b) add preconditions to all the SHA-1 Rxxxx as: "if SHA-1 is used, then...."

- Jacques to draft what a solution w option 4 could look like.

- Ram: Extensibility point could help.

- Pim: SHA256 may later be out of favor. So extensibility points may keep the door open for future options.

- Pim: WS are used for mission critical apps. SHould be able to find experts.

We hear of algorithms being updated all the time.

- Tom: we don't have much resources. But would we need to do testing? update test suites?

- Ram: question if adding new reqs on SHA256 would go beyond just "maintenance" charter for the TC.

- Pim: several companies already use profiles with SHA256

- Ram: are these user companies (in some vertical), or IT vendors?

- Pim: both.

- Ram: should we invite them to help upgrade the profile, what requirements they think are useful

about SHA upgrades?

- Action item: Pim to identify them & talk to them.

- Ram: will attempt to also connect with end-users.

- Ram: editorial comment still remain before CS.

(comment sent from Ram about minor edits for {BP12, BP20, RSP10} to be addressed before approving CS.)

ws-brsp message