Open ArneBruinse opened 3 years ago
Diagram ter beschrijving van de workflow voor het signen
We hebben voor nu besloten:
@ElisabethKloren voor de notulen: Wij hebben een stukje (probeer)software weten te bouwen , waarmee een visi bericht de digitale handtekening geïnjecteerd kan krijgen. Verder hebben we opgemerkt dat XADES BLT op de W3C site op dit moment XADES-X-L heet. @edelater kijkt namens Future Insight voorlopig alleen mee we sturen tzt de ontwerpen toe ter review.
Verdere info vanuit de werksessie:
Bakker&Spees gaat nu verder met:
We hebben afgesproken dat zodra we bij bovenstaande punten genoeg vertrouwen hebben dat we op de goede weg zitten, dat we dan @jvgeijlswijk uitnodigen om deze oplossing te laten verifiëren door de programmeurs van Technia en evt een samenwerkingsbijeenkomst voor de programmeurs te regelen.
Aanscherping van de eerdere afspraken:
We gaan XADES-B-LT (Basic-Longterm) in enveloped vorm NB: deze vorm heet op de W3C site op dit moment "XADES-X-L"
(plaatje gekopieerd van deze W3C site:)
https://www.w3.org/TR/XAdES/#Syntax_for_XAdES
Distinguished name met department name in het PSB
Signature value van het bericht in de inhoud van de confirmation. Door het signen van die confirmation is ieder bericht uiteindelijk ondertekend door beide servers. Een van de bedachte redenen om hiervoor te kiezen, is dat de verzendende server dan een zelf niet na te maken bewijs van echtheid van het verzonden bericht heeft. Eenzijdige aanpassing op de verzendende server is dan ook niet meer mogelijk.
nieuwe hashing techniek nodig omdat MD5 zwaar verouderd en gecompromitteerd is. Voorstel is SHA-2.
de hashes van de bijlages moeten ook in de bericht XML toegevoegd worden zodat die mee ondertekend worden
Het is belangrijk om de CanonicalizationMethod ook vast te leggen in de systematiek - nog te onderzoeken welke goed werkt
De minimale eis aan een certificaat in productie omgevingen is dat deze een trusted certificate is dat herleidbaar is naar een vertrouwde uitgever van certificaten, zoals PKI.
De namespace voor de 1.7 zojuist met Niek en Jeroen afgestemd, dit wordt:
Proefimplementatie is gedaan door Bakker & Sppes met SignedXml in .Net framework. Er is ook een Javabibliotheek. Links hierna volgen...
Vanochtend hebben @jvgeijlswijk @ArneBruinse en Niek besproken dat we het Xades signen volgens de hierboven benoemde .net oplossing gaaan inbouwen in een eerste proef 1.7 software.
Hierboven hebben we daarvoor de 1.7 namespace bepaald.
Acties die hierbij gaan horen: We moeten onderzoeken of we zonder problemen met de promotor krijgen het veld "checksum" aan iedere appendix toe kunnen voegen, net zoals nu in de visi xml's de velden "name" voor de bestandsnaam hebben.
In de documentatie moeten we opnemen dat er library's voor zowel .net als java beschikbaar zijn. De java librarys staan op deze EU-site: https://ec.europa.eu/digital-building-blocks/DSS/webapp-demo/home
In een eerder stadium is al de keuze gemaakt voor XAdES-BASELINE-LT Op basis van de recente proef ondertekening kiezen we in eerste instatie voor de packaging methode "Enveloped", waardoor de ondertekening echt een onderdeel van het visi XML bericht kan zijn.
Er moet nog uitgezocht worden welke "Digest algorithm" gekozen gaat worden, in een eerdere comment wordt gesproken over "SHA2", maar deze staat niet in de DEMO omgeving van de EU: https://ec.europa.eu/digital-building-blocks/DSS/webapp-demo/sign-a-document Ik vraag in ieder geval binnen B&S na of iemand daar een advies over kan geven.
@jvgeijlswijk in de documentatie en in bestaande VISI bericht xml 's kwam ik dit tegen:
En in de _5 staat hij ook erbij: ENTITY AppendixTemplate; name : STRING; fileLocation : STRING; fileType : STRING; fileVersion : STRING; documentIdentification : OPTIONAL STRING; documentVersion : OPTIONAL STRING; documentReference : OPTIONAL STRING; objectCode : OPTIONAL STRING; startDate : OPTIONAL DATETIME; endDate : OPTIONAL DATETIME; state : OPTIONAL STRING; dateLaMu : OPTIONAL DATETIME; userLaMu : OPTIONAL STRING; language : OPTIONAL STRING;
message : MessageTemplate; appendixGroup : OPTIONAL AppendixGroup; template : ComplexElementTemplate; END_ENTITY;
Mij lijkt een checksum een vorm van documennt identificatie. Lijkt het jou/jullie een goed idee om hier de checksums van de bijlagen in te stoppen, zodat de bijlagen mee ondertekend worden zonder dat er een nieuw attribuut bijgemaakt moet worden? Of liever op dezelfde manier een nieuw veld "checksum"?
Zojuist besloten in de werksessie: Deze aanpassing maakt de nog nooit toegepaste central soap server oplossing overbodig. In de visi 1.7 documentatie zal daarom alle verwijzingen naar central soap server verwijderd worden.
Hierbij het verslag van de uitkomst van de Xades bespreking van de EC van vandaag:
in de visi EC standus van 16 en 23 januari '24 zijn deze aanvullingen afgestemd:
message : MessageTemplate; appendixGroup : OPTIONAL AppendixGroup; template : ComplexElementTemplate; END_ENTITY;
bij een enkelvoudige fout: <SOAP-ENV:Envelope ...>
https://github.com/bimloket/visi/issues/70#issuecomment-706164305
Zie issue #70 voor de oorspronkelijke uitvraag. Met dit issue wordt de eerste oplossingsvorm voor deze vraag verder uitgewerkt middels het ondertekenen van berichten.