Prio-192: Waarborgen integriteit en authenticiteit van VISI-berichten

[JanaxLooij]

Omschrijving Aantonen dat de inhoud van een bericht onderweg niet is gewijzigd. De ontvangende partij heeft ten aanzien van een ontvangen bericht geen 100% zekerheid dat de integriteit en authenticiteit gewaarborgd is. Een ontvangen bericht kan onderweg gewijzigd zijn (bijvoorbeeld: aan een bedrag zijn een paar nullen toegevoegd, of een bijlage is verwijderd; of een ontvangen bericht is niet daadwerkelijk door de afzender verstuurd, maar door een persoon die de naam van de afzender gebruikt). Dat moet worden afgevangen.

Dit item houd zich niet bezig met de vraag of de juiste persoon binnen een organisatie het bericht heeft verstuurd. Deze validatie is aan de organisatie die gebruik maakt van de VISI software. Binnen de software zijn hiervoor wel zaken te regelen als two-pass authentication, hardware keys en dergelijke.

Motivatie In de VISI-systematiek is niet voorzien in het gebruik van digitale handtekeningen. Een PersonType en PersonTemplate heeft geen eigenschap voor het vastleggen van een digitale handtekening. Er zijn drie redenen waarom men een digitale handtekening wil gebruiken om (juridische) transacties te laten plaatsvinden: Authenticiteit, Integriteit en Onweerlegbaarheid. Extra controle op veilige en vertrouwde communicatie.

Impact Het ontbreken van een Authenticiteit, Integriteit en Onweerlegbaarheid heeft de volgende impact: -Juridische geldigheid van VISI wordt in twijfel getrokken; -Betrouwbaarheid van VISI is niet gegarandeerd; -Volwassenheid van VISI staat ter discussie.

Oplossingsrichting Voorgesteld wordt om een oplossing op basis van digitale handtekening met publieke en private sleutels te werken. Meer hierover is te lezen op Wikipedia en op Rijksoverheid.nl

Een certificaat is een computerbestand dat fungeert als een digitaal paspoort voor de eigenaar van dat bestand. Een digitaal certificaat is een combinatie van identiteit en openbare sleutel, die gewaarmerkt is door de uitgever c.q. certificaatautoriteit (CA). Het certificaat kan door de eigenaar worden gebruikt om een digitale handtekening te plaatsen onder een e-mailbericht of een bestand, waardoor het niet meer ongemerkt te muteren is (integriteit van het bericht) en vaststaat wie het verzonden heeft (authenticiteit van de bron).

Bij deze oplossing geeft de verzender - voordat de communicatie begint - zijn publieke sleutel aan de ontvanger. Daarna verstuurd de verzender zijn bericht dat is getekend met zijn private + publieke sleutel. De ontvanger kan dan met de eerder ontvangen publieke sleutel zien dat het bericht valide is.

Er is binnen de werkgroep gediscussieerd op welk niveau de publieke sleutels moeten worden overgedragen. Dit kan per persoon, per project, per organisatie of per soapserver. Uit de discussie kwam als conclussie dat dit het beste per organisatie gecommuniceerd kan worden, bijvoorbeeld in het metaraamwerk. Voordeel hiervan is dat gebruikers niet worden lastig gevallen met digitale handtekeningen. Door de publieke sleutel per organisatie vast te leggen in het PSB kan een organisatie regelmatig haar publieke sleutel veranderen.

Het is niet de bedoeling dat de berichten encrypted worden, er wordt alleen een sleutel meegeleverd die verklaart en bewijst dat het bericht valide is.

De exacte uitwerking van dit onderwerp is beschreven in het document Integriteit en authenticiteit van VISI berichten.pdf. In dit document wordt in het metaraamwerk aan het ComplexElement CeOrganisatieSOAPServer een verplicht SimpleElement publicKey toegevoegd.

Acties

artikel over juridische implicaties bijvoegen (actie: JvG=gedaan); bepalen of het artikel afdoende is (actie: Ge=gedaan); vastleggen van besproken oplossingsrichtng (actie: Ge=gedaan); herzien van technische oplossing i.v.m. technische issues en overlap met DigiKoppeling (actie: Ge=gedaan); afstemmen met Logius over DigiKoppeling (actie: Roy=gedaan); doornemen van Logius documenten: Koppelvlakstandaard WUS, Koppelvlakstandaard Grote Berichten, Protocolbindingen voor StUF. concept versie maken van Protocolbindingen voor VISI (actie: Ge); concept implementatie maken van Protocolbindingen voor VISI (actie: Ge, JvG);

definitieve versie maken van Protocolbindingen voor VISI (actie: Paul Jansen).

Opmerking Dit item betreft dezelfde functionaliteit als Workitem 1012. Dat item komt bij deze te vervallen

Attachments

CROWetcetera - pagina1.jpg CROWetcetera - pagina2.jpg 2012-08-28-juridische-implicaties-van-het-werken-met-bim.pdf Integriteit en authenticiteit van VISI berichten.pdf Integriteit en authenticiteit van VISI berichten.docx 20160715 v1 Presentatie Digikoppeling Crow.pdf stuf.bindingen.030203.pdf

This work item was migrated from CodePlex

CodePlex work item ID: '1010' Vote count: '2'

[JanaxLooij]

[jvgeijlswijk@25-10-2013] Het artikel over de "Juridische implicaties van het werken met BIM" uit maart 2009 is bijgevoegd.

[JanaxLooij]

[UnknownUser@25-10-2013]

[JanaxLooij]

[UnknownUser@28-2-2014]

[JanaxLooij]

[UnknownUser@28-2-2014]

[JanaxLooij]

[UnknownUser@28-2-2014]

[JanaxLooij]

[UnknownUser@28-2-2014]

[JanaxLooij]

[UnknownUser@28-2-2014]

[JanaxLooij]

[UnknownUser@25-3-2014]

[JanaxLooij]

[UnknownUser@25-3-2014]

[JanaxLooij]

[UnknownUser@10-4-2014]

[JanaxLooij]

[UnknownUser@11-4-2014]

[JanaxLooij]

[UnknownUser@11-4-2014]

[JanaxLooij]

[UnknownUser@5-9-2014]

[JanaxLooij]

[gspees@5-9-2014] Leesbaar pdf van Juridische implicaties toegevoegd

[JanaxLooij]

[UnknownUser@5-9-2014]

[JanaxLooij]

[UnknownUser@5-9-2014]

[JanaxLooij]

[UnknownUser@5-9-2014]

[JanaxLooij]

[jvgeijlswijk@5-9-2014] Dit punt is op 5 september 2014 centraal besproken (Jos Hamilton, Peter Willems, Ge Spees, Jeroen van der Burg, Taco Wannee, Jeroen van Geijlswijk). Public en private keys zijn behandeld en op welk niveau dit opgeslagen kan worden (VISI-leverancier, soap server, Organisatie, Persoon). Het besprokene wordt samengevat en bij de gebruikersgroep teruggelegd of dit wenselijk is.

[JanaxLooij]

[gspees@5-9-2014] Artikel juridische implicaties doorgelezen maar dat heeft geen raakvlak met de problematiek van dit issue

[JanaxLooij]

[UnknownUser@5-9-2014]

[JanaxLooij]

[UnknownUser@5-9-2014]

[JanaxLooij]

[UnknownUser@5-9-2014]

[JanaxLooij]

[UnknownUser@5-9-2014]

[JanaxLooij]

[UnknownUser@7-9-2014]

[JanaxLooij]

[UnknownUser@19-9-2014]

[JanaxLooij]

[UnknownUser@23-9-2014]

[JanaxLooij]

[jholweg@16-1-2015] Eerste aanzet is gemaakt, zie bijgevoegd document.

[JanaxLooij]

[UnknownUser@16-1-2015]

[JanaxLooij]

[jholweg@16-1-2015] "Bijgevoegd document" is "Integriteit en authenticiteit van VISI berichten.pdf"

[JanaxLooij]

[UnknownUser@27-2-2015]

[JanaxLooij]

[UnknownUser@27-2-2015]

[JanaxLooij]

[jholweg@27-2-2015] Nieuwe versie toegevoegd met certificaat infrastructuur om beter gebruik te maken van standaard security infrastructuur. Zie "Integriteit en authenticiteit van VISI berichten.pdf"

[JanaxLooij]

[gspees@16-10-2015] mogelijkheden om te testen:

• soapxml aanpassen voor verzenden
• public key bij ontvangende partij veranderen
• private key bij verzendende partij veranderen

[JanaxLooij]

[UnknownUser@16-10-2015]

[JanaxLooij]

[UnknownUser@16-10-2015]

[JanaxLooij]

[UnknownUser@16-10-2015]

[JanaxLooij]

[jvgeijlswijk@19-2-2016] In het message zit de signature in het VISI-bericht (visiXML_MessageSchema). En in de confirmation message zit de signature in de SOAP header. Dit is niet logisch.

Jaap Holweg schreef op 19-02-2016: "Dat gelijk trekken klinkt wel logisch. Er was een hele goede reden om dit zo te doen: eerst maar eens opschrijven hoe het functioneel ongeveer zou moeten (dat was deze spec), en vervolgens review van de technici vragen op de implementeerbaarheid. Daar is deze feedback niet op gekomen, en dus is het zo definitief geworden. Kortom: niet een bewuste keuze om dit onderscheid te maken – sowieso mooier om het op 1 manier te doen, en als het het implementatie-technisch ook nog eens makkelijker maakt, zou ik het z.s.m. veranderen!"

[JanaxLooij]

[jvgeijlswijk@19-2-2016] Originele versie van specificatie is bijgevoegd.

[JanaxLooij]

[UnknownUser@19-2-2016]

[JanaxLooij]

[jvgeijlswijk@8-4-2016] Gé heeft een e-mail stuurt naar forumstandaardisatie@logius.nl met het verzoek voor een gesprek met iemand die technisch deskundig is in de materie van Digikoppeling.

Digikoppeling gebruikt ook wsdl, SOAP en signatures, dus mogelijk kunnen zij ons helpen aan een correcte technische oplossing.

[JanaxLooij]

[jvgeijlswijk@15-7-2016] Release is aangepast van 1.5 naar 1.7.

[JanaxLooij]

[jvgeijlswijk@15-7-2016] Presentatie over DigiKoppeling van Pieter Hering (logius) is toegevoegd.

[JanaxLooij]

[UnknownUser@15-7-2016]

[JanaxLooij]

[UnknownUser@15-7-2016]

[JanaxLooij]

[jvgeijlswijk@15-7-2016] N.a.v. het overleg met Logius hebben we de volgende aandachtspunten:

• Koppelvlakstandaard WUS doornemen;
• Koppelvlakstandaard Grote Berichten doornemen;
• Protocolbindingen voor StUF doornemen.

[JanaxLooij]

[UnknownUser@15-7-2016]

[JanaxLooij]

[gspees@9-9-2016] In werksessie van 9 september 2016 is besloten dat Waarborgen integriteit en authenticiteit van VISI-berichten het beste kan worden opgelost met DigiKoppeling. Om deze reden wordt dit werkitem gesloten en verder opgenomen in werkitem 4613 Prio-323: Open Standaard Digikoppeling gebruiken voor communicatie tussen SOAP servers

[JanaxLooij]

[UnknownUser@9-9-2016]

[JanaxLooij]

Issue closed by gspees with comment Wordt verder afgehandeld in werkitem 4613 Prio-323: Open Standaard Digikoppeling gebruiken voor communicatie tussen SOAP servers