Nieuwe regels over elektronische documenten en voorwaarden

Excuses voor de vertraging, maar ik moest het even nazoeken. Zoals donderdag beloofd: wat is er per 1 juli gewijzigd over algemene voorwaarden en de rechtsgeldigheid van elektronische documenten?

De regels over algemene voorwaarden (art. 6:234 BW) zijn veranderd. Het wetsartikel is herschreven, met name om de leesbaarheid te vergroten (voor zover haalbaar, het is en blijft een draak van een artikel).

Een belangrijke wijziging is dat je nu ook bij “gewone” (niet-elektronische) contracten de algemene voorwaarden elektronisch mag aanleveren. Je mag dus een papieren contract tekenen (of een mondelinge overeenkomst sluiten) waarbij je de voorwaarden als PDF mailt. Wel vereist dit “uitdrukkelijke instemming van de wederpartij”. Het is dus niet toegestaan om in de algemene voorwaarden te zetten “Wederpartij verleent hierbij uitdrukkelijke instemming voor elektronische aanlevering van deze voorwaarden”. Niet dat dat veel mensen ervan zal weerhouden om het toch te doen (t-shirt voor de spotter van het eerste voorkomen hiervan.)

Een grotere wijziging is artikel 156a Rechtsvordering over elektronische akten – ondertekende geschriften die als bewijs dienen. Zo’n document mag nu ook elektronisch, mits (pas op, juridische mond vol):

het degene ten behoeve van wie de akte bewijs oplevert, in staat stelt om de inhoud van de akte op te slaan op een wijze die deze inhoud toegankelijk maakt voor toekomstig gebruik gedurende een periode die is afgestemd op het doel waarvoor de akte bestemd is te dienen, en die een ongewijzigde reproductie van de inhoud van de akte mogelijk maakt.

Ik kan daar niet veel meer van maken dan “je moet kunnen nalezen wat er getekend is” maar ongetwijfeld zitten hier heel veel nuances aan. Een PDF met elektronische handtekening voldoet aan deze eis.

Deze regels zijn ingevoerd op grond van het wetsvoorstel over elektronische aktes, dat met name bedoeld was om elektronische verzekeringspolissen mogelijk te maken. Logischerwijs is er dan ook een wetsartikel ingevoerd (art. 7:932 BW) dat zegt dat verzekeringspolissen nu elektronisch mogen. En dat gaat vrij eenvoudig met de bovengenoemde wijzigingen: die polis is een akte en moet dus voldoen aan de hierboven genoemde eis voor aktes, en de polisvoorwaarden zijn algemene voorwaarden en moeten dus voldoen aan de eisen van opslaanbaarheid. Plus, je mag bij een ‘gewone’ papieren polis nu met de verzekeringnemer afspreken dat de voorwaarden worden gemaild of te downloaden zijn.

Wel is er een extra eis aan de elektronische handtekening: die moet een “geavanceerdegekwalificeerde elektronische handtekening” zijn, en de mensen die weten wat dat betekent mogen nu de paracetamol grijpen. Inderdaad, dat is zo’n ding waarbij er geavanceerde wiskunde wordt gebruikt, een smartcard moet worden ingezet, een digitaal certificaat moet zijn verkregen en minstens 200 uren aan dure consultants moet zijn besteed voor het implementatietraject. Ik ben dan ook zeer benieuwd wanneer de eerste elektronische polissen daadwerkelijk aangeboden worden – en of ze ook echt gaan voldoen aan die voorwaarden.

Arnoud

28 reacties

  1. Goed om te zien dat de wet hierin veranderd. Mee met de tijd zullen we maar zeggen.

    Ik begrijp ook heel goed [de/je] frustratie ten aanzien van de 200 uur aan dure consultants waarna blijkt dat een student van de UT/TU er toch in slaagt om deze te kraken. (Hallo OV-Chipkaart) Doch, vanuit het perspectief van de verzekeraar kan ik me voorstellen dat een paar ton aan investering voor een verzekeraar niet direct heel spannend is. Perceptie.

    Consultancy is een goed voorbeeld van een traject waar de kostprijs volledig los staat van de verkoopprijs. Bij consultancy wordt de prijs bepaald door wat het waard is voor de opdrachtgever.

  2. Gezien de “ongewijzigde reproductie”, zou ik zeggen dat je het best PDF-A kunt gebruiken, PDF met alleen die aspecten die constant blijven over de tijd. Je kunt immers PDFs maken die na een bepaalde tijd andere inhoud laten zien met de ingebouwde JavaScript en een reeks andere truukjes. Het is redelijk simpel te doen in Word 2007, onder de PDF opties is een vinkje “ISO 19005-1 compliant (PDF/A)”. Adobe’s tools hebben ook zo’n setting.

    Die geavanceerde electronische handtekening is inderdaad hoofdpijn verwekkend, maar ik lees het als “een plaatje van een handtekening er onder plakken geldt dus niet he!”.

    Er is in de EU-gedreven regelgeving over digitale handtekeningen een concept van “gekwalificeerde handtekening”, een techniek die van te voren goed gekeurd is dat hij aan die technische eisen voldoet. (Dus als je zo’n techniek keurt, dan hoort er geen discussie meer te zijn in de rechtbank of de techniek goed is. Als hij niet gekeurd is, dan kan het ter discussie komen.) EU-landen horen daar nationaal een organisatie voor aan te wijzen die die toetsing kan doen. Het is de gebruikelijke warboel van problemen (hoe vind je die organisaties, geldt een Spaanse toetsing ook in Nederland, wat is het echt waard?). Zo ver ik weet, is in Nederland Brightsight (oude TNO ITSEF) de enige organisatie die dat doet. (Full disclosure: ik heb daar lang gewerkt). Ik kan me niet herinneren ooit zo’n gekeurd product gezien te hebben.

    Inderdaad Arnoud: hoofdpijn land…

  3. iemand meldt: Volgens mij klopt de laatste alinea niet: voor een geavanceerde digitale handtekening is geen digitaal certificaat nodig (van een partij als diginotar). Dat maakt de implementatie ervan een stuk eenvoudiger dan de gekwalificeerde digitale handtekening

    Wat klopt?

  4. Artikel 7:932 BW zegt:

    Een polis die is opgemaakt op een wijze als bedoeld in artikel 156a lid 1 van het Wetboek van Burgerlijke Rechtsvordering moet zijn voorzien van een elektronische handtekening die voldoet aan de eisen, bedoeld in artikel 15a lid 2 van Boek 3 van het Burgerlijk Wetboek.

    Dat artikel 3:15a lid 2 BW vereist in item e

    e. zij is gebaseerd op een gekwalificeerd certificaat als bedoeld in artikel 1.1, onderdeel ss, van de Telecommunicatiewet

    En een gekwalificeerd certificaat is dan weer (art. 1.1tt Telecommunicatiewet)

    tt. gekwalificeerd certificaat: certificaat dat voldoet aan de eisen, gesteld krachtens artikel 18.15, tweede lid, en is afgegeven door een certificatiedienstverlener die voldoet aan de eisen, gesteld krachtens artikel 18.15, eerste lid;

    Volgens mij ontkom je dus niet aan het certificaat van de onafhankelijke dienstverlener?

  5. Mijn lezing is dat de wetgeving die Arnoud aanhaalt, de lat lager legt. Dus je moet tenminste een geavanceerde digitale handtekening hebben. Ik zou zeggen dat een gekwalificeerde handtekening daar aan voldoet, maar mogelijk te zwaar is.

    Het heeft niet echt iets te maken met certificaten overigens. Alle praktische handtekening mechanismen hebben een mechanisme waarin een public key aan een identiteit gebonden wordt (i.e. het certificaat). Gekwalificeerd of niet, dat hebben ze allemaal onder water.

    Waar het verschil in zit, is hoe die identiteit geverifieerd wordt, hoe vaak en vooral of dat mechanisme gecontroleerd is door een derde partij. Bij gekwalificeerde handtekening mechanismen moet bij elke handtekening het apparaat controleren dat hij een opdracht van een mens/rechtspersoon gekregen heeft. In praktijk betekent dat elke keer een PIN intypen om je smartcard open te zetten. En bij een gekwalificeerde handtekening hoort de implementatie daarvan met de aanvalsmogelijkheden gecontroleerd worden door zo’n derde partij. Een geavanceerde digitale handtekening heeft volgens mij niet van dat soort expliciete eisen van te voren.

    Als je het anders wil zien, is het een vraag van wanneer je de kosten van de check van het mechanisme wil betalen. Als je zekerheid wil, doe je dat van te voren (i.e. de gekwalificeerde handtekening). Als je het risico dat daar discussie over komt laag acht, dan kun je dat gewoon uitstellen tot wanneer er een belangrijke rechtszaak over komt waarin het mechanisme ter discussie komt.

    Ik heb de indruk dat die discussie over het mechanisme nooit echt voorkomt in een rechtszaak, dus dan is een gekwalificeerde handtekening waarschijnlijk overkill. Ik zou een klant adviseren om te kijken de mogelijke extra kosten van een gekwalificeerde handtekening mechanisme tegen de verwachte kosten van zo’n rechtszaak (of de verzekering daar tegen) af te zetten. Het zou me sterk verbazen als het de moeite waard is om grote extra prijs te betalen voor het “gekwalificeerd” zijn van het mechanisme, maar het zou goed kunnen dat er producten zijn die al concurreren en al getoetst zijn als “gekwalificeerd”.

  6. Behalve voor verzekeraars, lijkt mij belangrijker dat elektronische onderhandse akten nu ook dwingende bewijskracht hebben. Als ik het goed begrijp is daarvoor een gewone elektronische handtekening (3:15a lid 4) voldoende. Dus is een mailtje met ingescande handtekening, of pdf met ingescande handtekening, (juridisch) even sterk bewijs als een ondertekend (papieren) geschrift.

  7. Mjah, dan zal de rechter wel komen met “redelijkerwijs mag verwachten dat in staat is om zogenoemde pdf-bestanden te openen”.

    Rechters gebruiken altijd de woorden redelijk & billijk; no fun…

  8. Arnoud Engelfriet legt in zijn antwoord van 12 juli 2010 om 10.32 precies uit hoe heet zit met de soort handtekening die benodigd is op een polis van een verzekeraar. Goed om te melden dat dit dus een “gekwalificeerde handtekening” is en dat in het oorspronkelijke stuk abusievelijk door hem de naamgeving “geavanceerde handtekening” is gebruikt.

  9. Rechters mogen alleen naar naar redelijkheid en billijkheid oordelen op het moment dat ze hier toe worden opgeroepen door de wetgeving. De wet stelt duidelijk als criteria: A) het kunnen opslaan door de wederpartij en B) het toegankelijk zijn voor de wederpartij. Hoe de rechter tot het oordeel zou kunnen komen als aan deze creteria in 95% van gevallen beantwoorden dat ze dan toch gelden in 100% van de gevallen is mij onhelder.

    “Het bestand is voor u niet toegankelijk omdat u blind ben? Dat is pech hebben, 95% van de mensen zijn niet blind dus ze gelden toch!” Dit moet dan doorgaan voor redelijkheid en billijkheid?

  10. Alex, hoe moet ik als dienstverlener dan op afstand bepalen of mijn klant blind is? Tcp/ip heeft (vooralsnog) geen flag om evt. beperkingen van de gebruiker mee te geven. Wie zegt dat de klant nog schijfruimte vrij heeft om ’t bestand op te slaan…?

  11. Het is misschien een vreemd idee maar dat zou de dienstverlener natuurlijk kunnen vragen. Als een klant iets koopt bij een webwinkel dan weet je met 100% zekerheid dat deze overweg kan met HTML bestanden. Daarin kun je dan ook je algemene voorwaarden aanbieden. Waarom zou deze dienstverlener dan in hemelsnaam notabeneexclusief een ander bestandformaat willen hanteren, waarvoor hij aannames moet gaan maken? ???When you assume, you make an ass out of u and me.” – Oscar Wilde

    Een dienstverlener die dan nog de behoefte heeft om PDF bestanden aan te bieden kan dat er naast doen.

    De gebruiker heeft tevens aan de wederpartij de in artikel 233 onder b bedoelde mogelijkheid geboden, indien hij de algemene voorwaarden voor of bij het sluiten van de overeenkomst aan de wederpartij langs elektronische weg ter beschikking heeft gesteld
    1. op een zodanige wijze dat deze door haar kunnen worden opgeslagen en
    2. voor haar toegankelijk zijn ten behoeve van latere kennisneming
    of (…)

    Volgens mij komt de eerste voorwaarde er op neer dat de gebruiker de AV op zo’n dagen wijze moet aanbieden dat deze op te slaan zijn. En de tweede komt er m.i. op neer dat d? wederpartij het moet kunnen raadplegen. Een redelijke uitleg hiervan omvat m.i. niet de verplichting om ervoor te zorgen dat d? wederpartij voldoende schrijfruimte vrij heeft, maar wel om de AV in dat formaat aan te leveren dat d? wederpartij er ook daadwerkelijk mee kan. Een redelijke uitleg van een wetsartikel is iets anders dan lukraak billijkheid en redelijk toe passen, omdat een voorwaarde van wetsartikel je niet bevalt.

  12. Is er (behalve ik zelf) niemand verbaasd over het feit dat de wet een specifieke technische implementatie (namelijk x509 certificaten) voor beveiliging eist?

    Iemand een idee waarom daar voor gekozen is en niet voor iets in de lijn als “afdoende veilig”?

    Natuurlijk is “afdoende” dan natuurlijk een discussie punt maar ik denk dat dit redelijk langs de “stand de techniek” te leggen is. Misschien niet door de rechter zelf maar zeker wel met hulp van het NFI of deskundigen.

  13. @cruisefan: Ik weet deze specifieke achtergrond niet, maar in soortgelijke situaties is een vage “afdoende veilig” eis een onzekerheid in de implementatie van zo’n systeem. Termen als “stand der techniek” zijn enorm vaag en leiden tot heel verschillende interpretaties (had dat dan niet quantum crypto moeten zijn? Lattices? ECDSA? Watermarking?).

    Als ontwikkelaar zit je dan met het probleem dat je een duur ontwikkel traject ingaat waarvan je pas jaren later duidelijkheid krijgt of het goed genoeg is. Dat is een serieuze drempel voor de invoering van dat soort systemen. Het is vanuit de overheid best een stevige zet om dan een technologie aan te wijzen als “deze is goed genoeg, gebruik hem”. Het was makkelijker geweest voor ze om te zeggen “zoek het zelf later maar uit voor de rechter” maar dan krijg je dus die remmende invloed.

    Dus ja het is verbazingwekkend voor mij, maar meer omdat ze die extra stap naar een praktische standaard gezet hebben :-).

  14. @Wouter: In de privacywet (artikel 13 Wet Bescherming Persoonsgegevens) staat juist opzettelijk een vage norm. Je moet persoonsgegevens ‘afdoende’ beschermen gezien aard van de gegevens, doel van de verwerking en stand van de techniek. Het idee hier is juist dat je dan vrij bent om de beste oplossing te kiezen – mits je maar kunt uitleggen waar?m het de beste was.

    Nadeel van een technlogie voorschrijven is dat je er dan aan vast zit. Stel puur theoretisch dat blijkt dat X.509 een overgespecificeerd gedrocht van een standaard is dat niemand wil gebruiken, dan zadel je als wetgever de maatschappij wel met een probleem op.

    (Overigens staat in de wet nergens letterlijk X.509 maar is het wel zo ongeveer de enige manier waarmee je kunt voldoen aan de wet. En al die Powerpoints van mensen die alleen van X.509 hebben gehoord, helpen natuurlijk ook niet.)

  15. @Arnoud: Ja, dat zijn de argumenten voor het overlaten aan de markt inderdaad. Voordeel is dat je langer flexibiliteit houdt in de te kiezen oplossing, nadeel daarvan is dat je daardoor langer onduidelijkheid krijgt of je de juiste gekozen hebt. Wat beter is, nu ja dat ligt dus aan hoe nuttig de flexibiliteit is en hoe zwaar je die onduidelijkheid vindt wegen.

    En naar mijn mening is X.509 een ondergespecificeerd wangedrocht van een standaard waar je van alles in kunt stoppen behalve een nuttige betekenis van een handtekening verifieerbaar tegen het certificaat, maar laten we realistisch zijn: verifi?ren of iets getekend is met de public key in zo’n certificaat, dat is heel breed gedragen technologie.

  16. @Wouter Slegers; ik zie zeker het nadeel van “vaag” zijn maar dit nadeel is er ook voor heel specifiek zijn. Ik weet het niet meer exact maar in 1999/2000 had verisign een probleem (*) met hun pre-V3 certificaten. Zoals ik het lees voldoen die prima aan de huidige wetgeving maar waren niet ‘afdoende’.

    Ooit (voor het bekend worden) waren ze wel ‘afdoende’ maar met dit soort wetgeving is het erg uitkijken of je het wel kan fixen als het mis gaat. (In dit voorbeeld was dat geen probleem. De v3’s waren al beschikbaar.)

    Andersom als je iets beters hebt (bv. straks quantum encryptie wellicht?) dat dit wellicht niet voldoet omdat de wet er geen ruimte voor biedt.

    Ik denk zelf dat de wet geen ontwikkelrichtlijn zou moeten zijn.

    Beetje offtopic: er is natuurlijk een verschil tussen x509 en PKI. Ik denk dat Arnoud met:

    Stel puur theoretisch dat blijkt dat X.509 een overgespecificeerd …. wel met een probleem op.
    wel eens dichter bij de waarheid kan zitten dan je in de eerste instantie zou denken als je x509 vervangt met PKI. En eigenlijk eist (ik zie geen andere oplossing) de wet PKI.

    *) Background; het probleem was dat je met een user cert ook andere CSR’s kon signeren omdat de end-entitity en path-length niet (goed) gezet waren.

  17. Ik ben ook niet van mening dat het in de wet zou moeten staan, ik probeer alleen aan te geven wat voor een beslisruimte er is en wat voor een soort overwegingen er kunnen spelen.

    In Duitsland pakken ze het iets anders aan. Daar hebben ze richtlijnen buiten de wetgeving over wat de overheid (BSI, deel van binnenlandse zaken daar) als tenminste goed genoeg vindt voor een digitale handtekening. Die regels gaan over minimum eisen aan algorithmen, keylengths, aanvallen waartegen beschermd enzo. De lat ligt best hoog daar overigens, de eisen worden jaarlijks bijgewerkt en geven ook aan hoe lang ze geldig zijn (dus een product van nu is goed voor de komende 5 jaar, behoudens enorme doorbraken). Daarmee wordt de state of the art vast gelegd en kunnen ontwikkelaars verder. Daar zit wel een flinke brok werk achter natuurlijk.

  18. @Wouter Slegers: ik ken de Duitse wet- en regelgeving nog minder dan de onze maar zoals je het beschrijft lijkt me dat een hele aardige oplossing die onze buren gekozen hebben. Zo op het eerste oog de enige juiste (in mijn ogen dan).

    Ik ben het wel met je eens dat daar een flinke bak werk achter zit maar veel van dat werk wordt nu bij de overheid al gedaan. Kijk bijvoorbeeld maar naar de richtlijnen waar in aanbestedingen naar verwezen wordt. (Het VIR voor de overheid bijvoorbeeld). Die zouden dan bijvoorbeeld aangevuld kunnen worden. Maar goed; nu raak ik wel heel erg off-topic geloof ik.

  19. Zoals Wouter Slegers stelt: Bij gekwalificeerde handtekening mechanismen moet bij elke handtekening het apparaat controleren dat hij een opdracht van een mens/rechtspersoon gekregen heeft. In praktijk betekent dat elke keer een PIN intypen om je smartcard open te zetten.

    Hoe is dit te rijmen met de honderden polissen die verzekeringsmaatschappijen dagelijks verstrekken? Gaat de directie ’s avonds polis voor polis een PIN invoeren om de handtekening te zetten?

    Waarschijnlijker is dat er een meer of minder gekwalificeerd certificaat wordt aangeschaft, waarmee de handtekeningen machinematig worden gezet. De vraag is in hoeverre een dergelijke implementatie voldoet aan de wettelijke normen.

  20. @Wasp: Die eis van de PIN intypen komt van het voorbeeld protection profile dat de EU aangeeft als een goede manier om een gekwalificeerd handtekeningsmechanisme te keuren. Daar kunnen de individuele landen weer van afwijken in hun lokale invulling van die richtlijn. In Duitsland volgen ze dat heel strikt met allerlei extra eisen aan sleutellengtes, trusted readers met apart keyboard en/of display enzo.

    De intentie van die richtlijn en bijbehorende PP was toen om de “is het wel rechtsgeldig?”-drempel voor handtekeningen van individuen te verlagen met die gekwalificeerde handtekening mechanismen.

    Maar, in #5 argumenteert Arnoud voor mij overtuigend dat de nieuwe regels zeggen dat voor polissen naar individuen wel met zo’n certificaat gemaakt mag worden en dat dat ook/nu? een “gekwalificeerde handtekening” is.

    Die term “gekwalificeerde handtekening” lijkt dus veranderd te zijn in betekenis, van “gemaakt met een gekwalificeerd handtekening mechanisme” naar “gemaakt met een gekwalificeerd certificaat”, tenminste voor die polissen. En/of ze hebben die term nu dubbel gebruikt en hij betekent voor business to consumer iets anders dan voor consumer to rest. Duidelijker is het in ieder geval voor mij niet geworden.

  21. @Wouter: Inderdaad, erg duidelijk is het allemaal niet. Er zijn al partijen die digitale polissen aanbieden aan de consumer, waarbij volgens mij niet altijd gebruik wordt gemaakt van een handtekening die is “gemaakt met een gekwalificeerd certificaat”.

    Interessant om te zien hoe zich dat verder ontwikkelt.

Geef een reactie

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren, <UL>/<OL> voor lijsten, en <em> en <strong> voor italics en vet.