Re: [bdxr] Invitation to comment on Exchange Header Envelope (XHE) V1.0 - ends May 29th

[Pim van der Eijk <pvde@sonnenglanz.net>]

Here are some comments on the XHE specification

1.1.2

This states XHE is the successor of BDE and SBDH.  An overview of 
changes would be useful for users of these predecessor versions. Is it 
possible to automatically, without loss of information, convert from 
SBDH to XHE and back?  It seems the answer is no, as some structures in 
SBDH seem to have disappeared.

1.1.3

States that service and correlation information can be added. How is 
this done?

1.2.4

“validation” is a noun (“to validate” is a verb)

1.3

Use the suggested labels from 
http://docs.oasis-open.org/templates/w3c-recommendations-list/w3c-recommendations-list.html. 


In particular, change label “[XMLDSIG]” to “[XMLDSIG-CORE1]”,  to make 
clear you are referencing the 1.1 and not the 1.0 version.

1.4

If you reference the 1.1 for XML Signature, why are you referencing the 
v1.0 of XML Encryption and not the 2013 V1.1?

2.3

Why is there at most one From Party?    Theoretically,  for some use 
cases,  there could be multiple From Parties.

Why is there at least one To Party?  Theoretically, for some use cases,  
the recipient may not be known at the time the XHE is created (and 
possibly signed).

Missing elements:

To be able to use an XHE in conjunction with ebXML messaging and 
possibly other protocols, it is important to be able to record the Role 
of the From Party and the Role of the To Party.

To be able to use an XHE in conjunction with ebXML messaging and 
possibly other protocols, it is important to be able to record a 
correlation identifier.   This supports use cases to express that an XHE 
is a response to another XHE. SBDH had a CorrelationInformation block 
that seems to have disappeared.

To be able to use an XHE in conjunction with ebXML messaging and 
possibly other protocols, it is important to be able to record a 
conversation identifier.

If you don't want to define these in the XHE schema,  you could add an 
extensibility option to allow users  to add extension headers to the XHE 
header.

2.8

“reference to a business case, document or other issues”.  What do 
“business case” and “issues” mean in this context?

“login”, naming:  should this be “username” ?

Why are “login” and “password” specified as the mechanism to use for 
external references?   There are other mechanisms to control access to 
an external resource.  Threshold cryptography was invented for this 
requirement.

2.9.2

“Encryption Hash”, naming:   why are you calling this an encryption 
hash?  A hash value is about integrity, not confidentiality.

“Encryption Hash”, definition:   previous protocols were hardwired to 
MD5 or SHA1,  and regretted it when vulnerabilities were found in them.  
It's similarly not a good idea to hard-wire hashing to SHA256, as some 
day it too may no longer be secure.   Better to add an element 
indicating the algorithm used,  e.g. as an IETF/W3C algorithm identifier 
URI.

In some use cases,  there is a benefit to have multiple digests using 
different digest algorithms.

“Encryption Indicator”:  this will in general be indicated using other 
means, and a simple indicator will not be sufficient.  E.g. if you want 
to support CMS and XML Encryption,  you might want an element that 
indicates which encryption format you are using and more likely also 
have explicit substructures for the selected encryption formats.

Encryption formats like XML Encryption already have structures for 
references to key references, algorithms etc. There is no need to 
duplicate those.  In fact duplicating them creates potential 
interpretation and interoperability issues.

When using XML documents,  it would make sense to simply select XML 
Encryption and specify in detail how it is used.   XML Encryption can 
cover multiple types of keys including RSA and PGP.

You model encryption at the level of individual payloads.  It is 
theoretically possible that you would encrypt payloads individually, 
maybe for different audiences, but in practice the common use case would 
be that an entire envelope is to be encrypted, including all its 
payloads.  The current schema does not seem to provide this 
possibility.  By using XML encryption, there would be much more 
flexibility to selectively encrypt.

Similarly,  you model HandlingServiceId at the level of individual 
payloads.  These assume all payloads in the XHE are handled 
individually,  but if you are sending a bunch of payloads in an XHE,  
presumably there is some service to handle the combination of payloads.  
Your schema does not seem to provide this possibility.

This header seems to be the only remaining bit of SBDH “BusinessService” 
block.  The ServiceTransaction block has disappeared with all its QoS 
elements (e.g. TimeToAcknowledgeReceipt).  These elements are used by 
some users.


5.6.3  PayloadContent

This assumes the content is XML (or mostly XML, with some character 
escaping).   But if the content is binary, escaping does not make sense, 
but rather the content would be base64 encoded. To support this,  you 
need an indicator to specify the use of base64 encoding,  or a code list 
of encodings that includes base64 encoding.






On 27-04-18 22:50, Chet Ensign wrote:
> OASIS members and other interested parties,