Sander; Pim, et al;
We here in AU are now starting to hit a general situation where the two year anniversary of AS4 deployments are coming up for all players.
Thus the comments below re CEM are suddenly apposite; and an ideal time to propose a solution to this problem. Principally at issue are the following:
·
Certificates are expiring two years (exactly) since deployment and will cease operations if no (manual) intervention
·
New Certificates must be SHA-256; whereas old certificates are SHA 128 (by mutual agreement)
·
This will keep happening at random times and lead to network instability
·
Currently about 20 players; later this will escalate as new players come on line with AS4 based solutions.
This round of renewals is further complicated by the latter SHA upgrade die to the fact threat Certificate Vendors are not now issuing
any 128 bit certificates; only 256; claiming the former is obsolete!
Thus I am interested in helping to bring this item to a conclusion. If not; various parties will suggest their own solution based
on local conditions etc and avoid implementing a standards based and reliable cross vendor solution.
Ideally via such messages each B2B counterparty may “negotiate” by exchange of such defined messages a timely and seamless transition
to a new certificate. Additionally, we should be able to send a new certificate through the already trusted channel for deployment to counterparties; automating the upgrade “hands free”.
Is there an Issue Number etc as a reference at this point?
Regards,
David Tuke
Enterprise Architect
Oban Pty Ltd Ground Floor 19-23 Prospect St
Box Hill 3128 Australia
ABN 18 163 365 080
T: +61 3 9044 1702 M: 0408 017 962 F: +61 3 9044 1799
E:
David.Tuke@obansolutions.com.au W:
www.obansolutions.com.au ***NOTICE***
This e-mail may contain confidential or legally privileged material and if you are not the intended recipient, you are advised that Oban Pty Ltd does not consent to you reading or copying the material and does not waive any confidentiality or legal privilege
associated with it. This e-mail may also contain material which is protected by copyright and if you are not the intended recipient, you are advised that Oban Pty Ltd has not consented to your reproduction of the material and there is no intention to provide
you with an implied licence to exercise any of the rights of the copyright owner or an authorised licensee. If you have received this e-mail in error, please advise Oban Pty Ltd immediately by return e-mail or by telephone on 61-3-9236-1900.
The recipient of this e-mail is solely responsible for conducting such tests and virus scanning as may be necessary, before using any attachment, to ensure that the attachment does not
contain any virus and that use of the attached materials will in no way corrupt the recipient's data or systems or those of any other person.
From:
ebxml-msg@lists.oasis-open.org [mailto:
ebxml-msg@lists.oasis-open.org]
On Behalf Of Sander Fieten
Sent: Thursday, 4 June 2015 9:22 PM
To:
ebxml-msg@lists.oasis-open.org Subject: [ebxml-msg] Draft meeting minutes for May 13th meeting
MEETING MINUTES OF EBXML MESSAGING TC MEETING 13 MAY 2015
ATTENDANCE
Sander Fieten (chair)
Theo Kramer
Pim van der Eijk
Bram Bakx
AGENDA
Approval of previous minutes
Explanation on CEM (Certificate Exchange Management)
Issues
Approval of previous minutes
The meeting minutes of the April 8th are unanimously approved.
Explanation CEM
Pim provides an explanation on an e-mail he sent to the mail list about certificate exchange messaging (CEM). There was a draft for this at the IETF but currently there no work and progress on this. Certificate exchange however is often
a problem in user communities and therefor a standard would be useful. There are however different views on how to configure certificates: Some vendors/parties take a TradingPartner centric solution where other use a exchange based (agreement or P-Mode based)
solution. The proposal is based on the exchanged based configuration where certificates configured in an exchange can be replaced.
Pim indicates that the ebCore TC would be the TC to standardise this. Pim would like to get comments on the posted information. Theo asks if this would be a formal specification or a committee note. Pim thinks that it would be a formal
specification. Sander asks if there no other initiatives or solutions that solve this problem. WS-Trust does something similar but is very bound to web services. Theo will look within domain registry community to see if there are initiatives/standard used
to solve this.
Issues
Issue #15 was discussed. It is clear that there are P-Mode parameters missing that define how to report the error. Basically there are two options: use the “bracket” approach as already specified in Core spec or extra P-Mode parameters
for errors. Pim will add a comment to the issue to list which P-Mode parameters apply to reporting of errors.
On the mail list there was also a summary of a discussion with vendors on this topic. Pim will add reference in the issue to the mail list.
Theo points out that in the interop tests he has seen there are no signed error messages, and products also do not offer support for it at this date. It is also clear that in some situations the error can not be related to a P-Mode so no
signing configuration is available. In such cases the error has to be sent unsigned.
Request errata document
TC members agree to start with an errata document. Chair(s) will ask TC admin to create a template document.
AOB
Pim requests the chair(s) to ask Jamie Clark about the status of ISO approval of the ebXML specifications.
Next meeting
The next meeting is scheduled for June 10th