Hi Chet, sorry, I have to come back to the vulnerability issue again. It's great that OASIS is working on a policy document helping the TCs to handle these topics in a professional manner. But an ad-hoc poll in the DSS-X TC made it obvious that we don't want to wait any longer before disclosing our vulnerability. My approch would be to upload a document describing the problem and its remediation. Additionally I would like to upload a simple Proof-of-concept snippet to github. The next step would be mailing to our lists and a prominent message on TC's homepage describing the problem, a link to the mantioned document and PoC, the way to mitigate it in DSS core 1.0 and the confirmation that the problem is NOT present in DSS-X core 2.0! The third step is to give Mitre a hint that our CVE can be published. Do you consider this as a useful way to move forward? Greetings, Andreas Thanks Andreas - I'll be reviewing those with the committee. We have had discussion on those topics - just haven't reached consensus yet. /chet On Thu, May 21, 2020 at 5:08 PM Andreas Kuehne <
kuehne@trustable.de> wrote: Hi Chet, see my comments in Policy document. My major topic is that the complexity of a violnerability of standard (compared with a software flaw) is not addressed: - Who are the stakeholders? - How to contact them? - How to avoid unintended full disclosure by informing vulnerabilty traders? Greetings, Andreas Andreas, this is really interesting. We have two documents right now: - The Vulnerability Handling and Disclosure Policy at
https://docs.google.com/document/d/1Vx-ul_MTenguAmFZKnMS89yEu1YMbvRenJGk0D7N3KI/edit#heading=h.7m6wq9expm3e - The Vulnerability Handling and Disclosure Process at
https://docs.google.com/document/d/1qxp3EMq8KKq84smrAFyWlnL87oOrPj-kT9dxefjk5Pc/edit#heading=h.7m6wq9expm3e - the Process is the document that we'll put on the OASIS public pages to guide researchers who want to report findings. With the link, you can comment. You will see that we have had a lot of feedback already from members of the Open Projects Advisory Council. Feel free to add comments if you'd like. The Board Process Committee is reviewing these now with the intention to send these to the full Board for review soon. So, I want to be sure I understand your situation. I looked at the page on the Mitre site and I don't get a result for CVE-2020-13101. I see results for 2019- and 2018-. For 2020- I found ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided. Is it the TC that made the reservation? Assuming that's the case: that you all discovered a vulnerability, addressed it, and have reserved the identifier, can you tell me the story? How did you find out about it, how did you deal with it, etc. etc. This is a great education for me (and the rest of the committee I'm sure) and can help me make sure we are putting the right things in place. In terms of where to post the notice, that is a great question. I had not thought about that in detail. Your suggestion makes perfect sense - a link on the download section and a reference one the TC's home page. We may wind up needing a Vulnerabilities list somewhere on the OASIS site but for now, notice on the TC page may be enough. In any case, thanks - I'm looking forward to hearing more details. /chet On Mon, May 18, 2020 at 11:14 AM Andreas Kuehne <
kuehne@trustable.de> wrote: Hi Chet, We (the Board Process Committee to be precise) is working on a process document now. I'm happy to share the working draft if you'd like to review it. great! Would be a please or me to do a review! When you say file it officially, do you mean that the TC has already developed the fix and that you want to announce it in one of the vulnerability databases? Yes, the new version of the DSS-X core does not include the option for the attack. And it is pretty forward for users of the version 1 to avoid these probems. Just reject the 'inline XML' data transfer option. I thought of a warning iin the download section loke this and a corresponding hint on the TC home page. The vulnerability has the identifier CVE-2020-13101 assigned. Greetings, Andreas /chet On Sun, May 17, 2020 at 12:46 PM Andreas Kuehne <
kuehne@trustable.de> <
kuehne@trustable.de > wrote: Hi Chet, we already discussed the topic soe time ago: The DSS core V1.0 has a vulnerability and we like to file it officially. Is there an official OASIS process for it? If not, I would suggest that we add a remark including the link to the explaination & mitigation document and the CVE at a prominent place on the TC home page and at the standards download section. Gretings, Andreas -- Andreas KÃhne Chair of OASIS DSS-X phone: +49 177 293 24 97 mailto:
kuehne@trustable.de Trustable Ltd. Niederlassung Deutschland Gartenheimstr. 39C - 30659 Hannover Amtsgericht Hannover HRB 212612 Director Andreas KÃhne Company UK Company No: 5218868 Registered in England and Wales -- Andreas KÃhne Chair of OASIS DSS-X phone: +49 177 293 24 97 mailto:
kuehne@trustable.de Trustable Ltd. Niederlassung Deutschland Gartenheimstr. 39C - 30659 Hannover Amtsgericht Hannover HRB 212612 Director Andreas KÃhne Company UK Company No: 5218868 Registered in England and Wales -- Andreas KÃhne Chair of OASIS DSS-X phone: +49 177 293 24 97 mailto:
kuehne@trustable.de Trustable Ltd. Niederlassung Deutschland Gartenheimstr. 39C - 30659 Hannover Amtsgericht Hannover HRB 212612 Director Andreas KÃhne Company UK Company No: 5218868 Registered in England and Wales -- Andreas KÃhne Chair of OASIS DSS-X phone: +49 177 293 24 97 mailto:
kuehne@trustable.de Trustable Ltd. Niederlassung Deutschland Gartenheimstr. 39C - 30659 Hannover Amtsgericht Hannover HRB 212612 Director Andreas KÃhne Company UK Company No: 5218868 Registered in England and Wales