Re: [ebxml-msg] Id attribute

[Theo Kramer <theo@flame.co.za>]

See below for further input received from Ian on this topic

With that, and after last nights discussion I would propose that section 5.1.4 profiling rule (b) be amended as follows

AS4 MSH implementations are REQUIRED to include the entire eb:Messaging SOAP header block and the (possibly empty) SOAP Body in the signature. The eb:Messaging header for a signed message MUST be referenced either using the “id” attribute or the "wsu:Id" attribute.

> 
> Hi Theo,
>                  I was going to post this to the list, but because my organisation has changed its email domain, I am blocked at present until I get things sorted out. Please feel free to forward it.
>  
> These quotes from the specs are from a colleague of mine who has implemented a digital signature stack of his own and used it for web services as well as other purposes.
>  
> Regards, Ian Otto.
>  
>  
> Ian Otto
> Security Architect
> VANguard and Infrastructure Branch
> ICT Services Division
> __________________________________________
> Department of Industry
> SAP House, Level 8.49, Bunda Street, Canberra City ACT 2600
> GPO Box 9839, Canberra ACT 2601
> Ph: +61-2-6276 1660 Fax: +61-2-6213 6684
> Mobile: +61 403 458 215
> Email:  Ian.Otto@industry.gov.au
> Internet: http://www.innovation.gov.au
> ABN 74 599 608 295
>  
>  
>  
> From: Young, Malcolm 
> Sent: Thursday, 24 October 2013 10:44 AM
> To: Otto, Ian
> Subject: ID Elements in referencing [SEC=UNCLASSIFIED]
>  
> From WSS1.1
>  
> 490 There are many motivations for referencing other message elements such as signature
> 491 references or correlating signatures to security tokens. For this reason, this specification defines
> 492 the wsu:Id attribute so that recipients need not understand the full schema of the message for
> 493 processing of the security elements. That is, they need only "know" that the wsu:Id attribute
> 494 represents a schema type of ID which is used to reference elements. However, because some
> 495 key schemas used by this specification don't allow attribute extensibility (namely XML Signature
> 496 and XML Encryption), this specification also allows use of their local ID attributes in addition to
> 497 the wsu:Id attribute and the xml:id attribute [XMLID]. As a consequence, when trying to locate
> 498 an element referenced in a signature, the following attributes are considered (in no particular
> 499 order):
> 500
> 501 • Local ID attributes on XML Signature elements
> 502 • Local ID attributes on XML Encryption elements
> 503 • Global wsu:Id attributes (described below) on elements
> 504 • Profile specific defined identifiers
> 505 • Global xml:id attributes on elements
>  
> Further:
>  
> Tokens and elements that are defined in this specification and related profiles to use wsu:Id
> 512 attributes SHOULD use wsu:Id. Elements to be signed MAY use xml:id [XMLID] or wsu:Id,
> 513 and use of xml:id MAY be specified in profiles. All receivers MUST be able to identify XML
> 514 elements carrying a wsu:Id attribute as representing an attribute of schema type ID and process
> 515 it accordingly.
> 516
> 517 All receivers MAY be able to identify XML elements with a xml:id attribute as representing an ID
> 518 attribute and process it accordingly. Senders SHOULD use wsu:Id and MAY use xml:id. Note
> 519 that use of xml:id in conjunction with inclusive canonicalization may be inappropriate, as noted
> 520 in [XMLID] and thus this combination SHOULD be avoided.
>  
> Note my bold above: This is a should which is why Java probably errs towards it. If it doesn’t recognise other ID elements, it’s not broken, just lacking broader support.
> Malcolm Young
> Solution Architect and Manager Service Development Section
> VANguard and Infrastructure Branch
> ICT Services Division
> Department of Industry 
> GPO Box 9839, Canberra ACT 2601
> SAP House, Level 8.80, Bunda Street, Canberra City ACT 2600


On 21 Oct 2013, at 15:54 , Theo Kramer <theo@flame.co.za> wrote:

> Thanks Pim - so we have a situation where sig references must either be followed for verification using either the optional 'id' (of type xdd:ID) in the eb:Messaging element or may also use wsu:Id, but always wsu:Id for all other elements such as Body. 
> 
> Is this not counterintuitive ?
> 
> Interestingly the current xwss libs also do not cater for this difference… and throw a WSS0285 error if no wsu:Id reference can be found ( uses xpath =  "//*[@Id='" + id + "']"; )
> 
> Would it not be better to update section 5.1.4 rule b of the as4 profile as follows ?
> 
> AS4 MSH implementations are REQUIRED to include the entire eb:Messaging SOAP header block and the (possibly empty) SOAP Body in the signature. The eb:Messaging header MAY be referenced using the “id” attribute or the "wsu:Id" attribute.
> 
> Further comments/input on this much appreciated.
> 
> On 11 Oct 2013, at 09:00 , Pim van der Eijk <pvde@sonnenglanz.net> wrote:
> 
>> 
>> Hi Theo,
>> 
>> There is an "id" attribute defined in the ebMS3 header schema,  of type xsd:ID.  The signature can therefore reference the eb:Messaging element using a reference to this attribute.  The wsu:Id attribute is useful to add to elements that do not have an identifying attribute themselves,  such as the SOAP Body element.
>> 
>> Pim
>> 
>> On 10/11/2013 08:15 AM, Theo Kramer wrote:
>>> I think we have a problem in both the core spec and the as4 profile in the case of the Id attribute
>>> 
>>> In section 5.1.4 profiling rule b of the as4 profile we have the following
>>> 
>>> AS4 MSH implementations are REQUIRED to include the entire eb:Mes- saging SOAP header block and the (possibly empty) SOAP Body in the sig- nature. The eb:Messaging header SHOULD be referenced using the “id” attribute.
>>> 
>>> My reading of section 4 of the Web Services Security: SOAP Message Security 1.1 (WS-Security 2004) would indicate that ebove is incorrect, ie. "id" should be "Id".
>>> 
>>> The examples both in the core spec and the as4 profile also use "id" instead of "Id".
>>> 
>>> This looks wrong to me.
>>> 
>>> Appreciate any comments on this.
>>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
> 
> -- 
> Regards
> Theo
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

-- 
Regards
Theo