RE: Current status, and BSP issue

Ram:

The way I see we might answer (or rather elude) your question and at the same time resolve this inconsistency in BSP11:

- Treat SHA version as an “Extensibility point” with “profile-covered alternative(s)”.

Some of our Extensibility points allow for alternatives to a feature covered in the profile (i.e. that has Rxxxx to it), but leaving the alternatives uncovered and out of Profile scope (i.e. falling under the Extensibility mechanism and subject to out-of-band agreement).

For example in BP, the following Extensibility point with “profile-covered alternative”:

E0029 - Use of messages other than SOAP 1.1 or XOP messages - Use of Messages other than a SIMPLE_SOAP_MESSAGE or a XOP_ENCODED_MESSAGE is an extensibility pointCORE TESTABLE

Here we have an E.P. that allows for message formats other than SIMPLE_SOAP_MESSAGE or a XOP_ENCODED_MESSAGE. Yet the Profile assumes/prefers these above formats and makes Rxxx about them. Should an alternate format be preferred by users, they would do an out-of-band agreement and the Rxxxx for SIMPLE_SOAP_MESSAGE would not apply. Note that these Rxxxx are conditional:

R1018 A SIMPLE_SOAP_MESSAGE MUST indicate the correct character encoding, using the "charset" parameter. CORE TESTABLE BP1018

So if you are not a SIMPLE_SOAP_MESSAGE then this Rxxxx does not apply.

This is not the only Extensibility point with “profile-covered alternative(s)”.

For our present case, that would mean adding a new E.P. to BSP11:

E0nnn – Digest algorithms – Use of algorithms other than SHA-1 is an extensibility point.

Then the following requirement may be reworded in a conditional way:

R5210 Any STR_KEY_IDENTIFIER that references an X509_TOKEN which does not contain a SubjectKeyIdentifier extension MUST have a ValueType attribute with the value of "http://docs.oasis-open.org/wss/oasis-wss-soap-message-security-1.1#ThumbprintSHA1 and MUST contain the value of the SHA1 of the raw octets of the X509_TOKEN that is referenced."

Replaced with:

R5210b When the use of SHA-1 is agreed, any STR_KEY_IDENTIFIER that references an X509_TOKEN which does not contain a SubjectKeyIdentifier extension MUST have a ValueType attribute with the value of "http://docs.oasis-open.org/wss/oasis-wss-soap-message-security-1.1#ThumbprintSHA1 and MUST contain the value of the SHA1 of the raw octets of the X509_TOKEN that is referenced ."

There is no test assertions defined for BSP, but there is a test suite. I don’t know if this test suite considers the possible use of other SHA versions, but if it verifies R5210 above, it would normally fail an implementation that uses something else than SHA-1. Because of this I would rename R5210 as R5210b, and leave R5210 in but make a note it is deprecated/replaced, as it is only relevant to SHA-1 users. Then the test suite/tool must be distributed with an errata, if not updated.

To be discussed… I am not claiming that we can easily reword/replace these 4 Rxxxx to not be exclusive of other Digest algorithms.

But the direction of making the Digest algorithm an E.P. seems to me consistent with the intent to make SHA-1 not an exclusive choice (even if “preferred”) – and also give a way forward to current users.

Thanks,

-jacques

From: Ram Jeyaraman (MS OPEN TECH) [mailto:Ram.Jeyaraman@microsoft.com]
Sent: Thursday, March 06, 2014 12:22 PM
To: Jacques Durand; ws-brsp@lists.oasis-open.org
Subject: 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