[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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...." (c) do not add any req for SHA-2+. - 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.) |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]