[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [bdxr-comment] Re: [bdxr] Invitation to comment on Exchange Header Envelope (XHE) V1.0 - ends May 29th
Dear Pim
Once again thanks for your comments. As promised, we have reviewed all comments received during the public review process and compiled a registry of our replies and resolutions:
https://www.oasis-open.org/committees/document.php?document_id=63711&wg_abbrev=bdxr
The comments have been implemented in a working draft here:
https://www.oasis-open.org/committees/download.php/63674/xhe-v1.0-csd02wd01-20180808-1420z.zip
As this is a joint project, the next step is to follow the UN/CEFACT public review process. Once the UN/CEFACT public review has been completed and any comments resulting from that have been implemented, the TC will formally decide whether to hold another OASIS Public Review.
Best regards,
Kenneth
ïOn 5/4/18, 2:28 PM, "bdxr-comment@lists.oasis-open.org on behalf of Kenneth Bengtsson" <bdxr-comment@lists.oasis-open.org on behalf of kbengtsson@efact.pe> wrote:
Thank you for your comments and observations, Pim. I have documented them so that they are included in the TC's revision process, and will be included in the formal resolution log.
Also copying Anders Grangaard, who is leading the project from UN/CEFACT's side.
Best regards,
Kenneth
On 5/3/18, 3:47 PM, "bdxr@lists.oasis-open.org on behalf of Pim van der Eijk" <bdxr@lists.oasis-open.org on behalf of pvde@sonnenglanz.net> wrote:
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,
>
---------------------------------------------------------------------
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]