EU- standaard Xades gebruiken om alle VISI berichten mee te Signen

[ArneBruinse]

#70 (comment)

Zie issue #70 voor de oorspronkelijke uitvraag. Met dit issue wordt de eerste oplossingsvorm voor deze vraag verder uitgewerkt middels het ondertekenen van berichten.

[JensCobussen]

Diagram ter beschrijving van de workflow voor het signen

[ArneBruinse]

We hebben voor nu besloten:

• We gaan XADES-B-LT (Basic-Longterm) in enveloped vorm
• Distinguished name met department name in het PSB
• Signature value van het bericht in de inhoud van de confirtmation. Door het signen van die confirmation is ieder bericht uiteindelijk ondertekend door beide servers.
• 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.

[ArneBruinse]

@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:

• Het zoeken naar een duidelijke uitleg voor om te beginnen onszelf hoe het nu werkt dat de ondertekening in het ondertekende bericht lijkt te zitten(wat niet logisch lijkt).
• het onderzoeken of de eerste voorbeeld XML bestand inderdaad op de juiste manier ondertekend is nu (XML file voeg ik ook bij dit bericht)
• Of we voorbeelden met 1 of meerdere bijlagen kunnen maken
• Hoe de confirmation aangepast moet worden om de (juiste)ondertekening van de verzendende partij als inhoud mee terug te sturen zodat de ontvangende server een extra handtekening op die informatie legt
• Hoe de uitgebreide confirmation ondertekend moet worden incl voorbeeld XML bestand

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.

[ArneBruinse]

De namespace voor de 1.7 zojuist met Niek en Jeroen afgestemd, dit wordt:

<visiXML_VISI_Systematics xmlns="http://www.visi.nl/schemas/20220930" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

[jvgeijlswijk]

Proefimplementatie is gedaan door Bakker & Sppes met SignedXml in .Net framework. Er is ook een Javabibliotheek. Links hierna volgen...

[ArneBruinse]

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.

[ArneBruinse]

@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"?

[ArneBruinse]

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.

[ArneBruinse]

Verslag Xades bespreking inhoudelijk expertcommissie 29 11 23.pdf

[ArneBruinse]

Hierbij het verslag van de uitkomst van de Xades bespreking van de EC van vandaag:

• We gaan met de 1.7 MVP van Xades alleen per softwarepakket 1 keypair genereren zodat we slechts maximaal 4 puplic keys hoeven te accepteren, naast eIDAS keys
• 1.7 berichten moeten dus minimaal met 1 van die 4 sleutel of een eidas key ondertekend zijn. Een niet xades ondertekend visi bericht is niet 1.7 compatible en moet dus geweigerd worden.
• Bakker&Spees probeert ook in samenwerking met KPN een koppeling te ontwikkelen zodat we onderling ook 100% valide xades berichten aan Eidas kunnen valideren.
• We gaan in 1.7 de confirmation uitbreiden met Signature value van het bericht in de inhoud van de confirmation en de confirmations ook ondertekenen.
• Canoncalisation method en hashing techniek is al vastgelegd in Xades.
• De melding “Distinguished name met department name in het PSB” negeren we omdat we nu geen aanknopingspunten en noodzaak zien. Mochten we dit toch nog tegenkomen, moeten we op dat moment een evntuele uitbreiding overwegen.
• In 1.7 moeten we ook proberen het veld "checksum" aan iedere appendix toe te voegen, zodat op die manier ook alle bijlagen ondertekend worden.

[ArneBruinse]

in de visi EC standus van 16 en 23 januari '24 zijn deze aanvullingen afgestemd:

• Het gaat over checksum info van de bijlagen, zodat de bijlagen op die manier mee-ondertekend worden als we het bericht ondertekenen.
  o Mark zorgt deze week voor een voorstel om met dezelfde techniek waarmee we nu een bericht onderteken, ook een controle string kunnen opbouwen per bijlage
  o Er staat in het github issue dat er een veld “Checksum” bij moet komen bij de bijlage info in het onderstaande _5exp element :
  Mark koppelt ook nog terug of de naam “checksum” goed is of anders moet worden.
  ENTITY AppendixTemplate;
  name : STRING;
  fileLocation : STRING;
  fileType : STRING;
  fileVersion : STRING;
  checksum : 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;

• Daarnaast moet in de confirmation de ondertekeningssleutel van het obntvangen bericht retour gestuurd worden en de confirmnation weer ondertyekend de deur uit. Dit, zodat de verzendende server weet dat haar bericht onaangepast is ontvangen en men in de toekomst ook archieven kan hebben met confirmations waardoor ieder soap bericht door beide servers is ondertekend/verzegeld.
  o In de oude documentatie kan ik dit terugvinden over de confirmation(dit mist nog in de nieuwe)
  De SOAP server van de ontvangende partij bouwt bij succes een SOAP reactiebericht op als volgt:
  <SOAP-ENV:Envelope ...>
  SOAP-ENV:Header
  <SOAPServerURL ...>
  http://192.168.0.102</sender>
  http://192.168.0.138</reciever>

UniqueIDonMessageInitiatingSOAPServer_XYZ

bij een enkelvoudige fout:
<SOAP-ENV:Envelope ...>
SOAP-ENV:Header
<SOAPServerURL ...>
http://192.168.0.102</sender>
http://192.168.0.138</reciever>

<SOAPCentralServerURL ...>


<UniqueID ...>
UniqueIDonMessageInitiatingSOAPServer_XYZ

</SOAP-ENV:Header>
SOAP-ENV:Body

Er is een fout opgetreden bij …

</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Bij meerdere fouten (bijvoorbeeld bij validatie van de xsd):
<SOAP-ENV:Envelope ...>
SOAP-ENV:Header
<SOAPServerURL ...>
http://192.168.0.102</sender>
http://192.168.0.138</reciever>

<SOAPCentralServerURL ...>


<UniqueID ...>
UniqueIDonMessageInitiatingSOAPServer_XYZ

</SOAP-ENV:Header>
SOAP-ENV:Body

Waarden van simpel element1 is niet volgens definitie
Waarden van simpel element2 is niet volgens definitie

</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

In geval van geen fout is de code 0, bij een onbekende fout is de code 1, deze foutmeldingen zullen moeten worden opgelost door de programmeurs. Alle foutmeldingen met een hogere code betreffen fouten die door de software begrepen kunnen worden.
o Het voorstel is om de confirmation als volgt uit te breiden hiervoor:
SOAP-ENV:Body

Waarden van simpel element1 is niet volgens definitie
Waarden van simpel element2 is niet volgens definitie

HierKomtDeOndertekeningscodeVanHetZojuistOntvangenBericht
</SOAP-ENV:Body>