RE: Current status, and BSP issue

How do we validate if the proposed changes actually ensure interoperability based on SHA-256?

I suspect more requirements (specific to SHA-256) are needed to guarantee that.

From: ws-brsp@lists.oasis-open.org [mailto:ws-brsp@lists.oasis-open.org] On Behalf Of Jacques Durand
Sent: Thursday, March 6, 2014 12:10 PM
To: ws-brsp@lists.oasis-open.org
Subject: [ws-brsp] Current status, and BSP issue

Folks:

Current status:

1. Editors are updating the disposition of comments” for BP1.2, BP2.0, RSP1.0. I modified the section 2.5 to restore the normative quality of the description of conformance claim mechanisms (keywords MUST, MUST NOT in 2.5.2), while clearly stating that these mechanisms have no bearing on conformance, and are not part of the Profile definition.

See attached the diffs in section 2.5 on BP1.2 (and in particular comments tagged TAB-317, TAB-278). We also state in 2.1 that the only portions of the Profile document that are normative are (1) the Requirements, (2) the conformance claim mechanisms in 2.5 (although optional).

If OK, that is the disposition we’ll put to vote soon by electronic ballot.

2. BSP11

Here we may have a bit of an issue. As brought to our attention by a user, (Pim V.D.E.), SHA-1 is kind of deprecated now.

The profile allows for other algorithms (In 9.6.1, SHA-1 is “preferred” not excluding other SHA versions).

But the following mandatory requirements do NOT consider any other alternative to SHA-1:

R4212, R5210, (these two really assume SHA-1 to be used)

R6906, R3072 (these two just require SHA-1 to appear in a string)

So there seems to be an inconsistency in BSP1.1 definition itself.

One way to unknot this could be to reword these SHA-1-assuming Rxxxx in a conditional way: add “If SHA-1 is used….”

Note that this is just a correction that removes restrictions to the intended acceptance of other SHA versions. An implementation currently conforming would still conform. And one using SHA-2 or -256 would NOT fail R4212, R5210.

If we do this:

- conditional narrowing of R4212, R5210 in order to ONLY apply to cases where SHA-1 is used.

- Possibly, same narrowing of for R6906, R3072

- Possibly, adding the choice of SHA (-1, -2 or -256) as an extensibility point, to make it clear it must be agreed upon.

A stronger stance would be to – in addition - alter the “preferred” status of SHA-1 (section 9.6.1) and make it just an option at same level as others

Opinion?

We may decide to process BSP11 apart from others, to address above inconsistency, i.e. its CSD + PR progress may be delayed 1 month compared to other profiles.

-jacques

ws-brsp message