About this blog…

I am employed by Netnod as head of engineering, research and development and am among other things chair of the Security and Stability Advisory Committee at ICANN. You can find CV and photos of me at this page.

As I wear so many hats, I find it being necessary to somewhere express my personal view on things. This is the location where that happens. Postings on this blog, or at Facebook, Twitter etc, falls under this policy.

The views expressed on this post are mine and do not necessarily reflect the views of Netnod or any other of the organisations I have connections to.

Arkitekturbeskrivning jag letar efter…

Jag skrev som vissa känner till en summering av de problem jag ser med tjänsten Mina Meddelanden. Det kom en del bra kommentarer, bl.a. en från Rutger Langland på Skatteverket som arbetar med tjänsten. Bl.a. detta svar från Rutger, en kort diskussion på veckans möte med Digitaliseringsrådet och diskussioner med diverse personer gör att jag tänkte jag måste förklara hur jag skulle byggt en sådan här tjänst. Att Rutger liknar det som jag nedan kallar en katalogtjänst vid IP-adresseringen på Internet, hmm…. Det de bygger är verkligen inte något som liknar IP-adresseringen, varken dess allokering eller dess användning vad gäller unik identifiering av objekt eller vägval.

Jag ser något som Mina Meddelanden består av ett par olika byggstenar. Låt oss ta dem en i taget.

  1. Avsändande partDet som vill skicka ett meddelande måste veta på vilket format det skall skickas, med vilket protokoll, och vart meddelandet skall skickas. Det måste helt enkelt vara glasklart hur en avsändande part ska bete sig för att meddelandet skall kunna skickas.
  2. Mottagande partMottagaren måste veta hur de ska bete sig för att ta del av ett meddelande som skickats till dem. Detta inkluderar naturligtvis att de verktyg som krävs för att ta emot meddelanden måste finnas där mottagaren finns. Både fysiskt och i cyberrymden.
  3. KatalogtjänstAvsändaren(s verktyg) måste kunna skicka meddelandet på korrekt sätt till rätt destination. Detta innebär att mottagaren måste på något sätt kunna annonsera till mottagaren avsändaren vart meddelanden skall skickas.
  4. NyckelhanteringFör att meddelanden skall kunna garanteras enbart kan läsas av mottagaren måste meddelanden vara krypterade på ett sådant sätt att enbart mottagaren kan dekretera dekryptera det. Samtidigt är det önskvärt att meddelanden är signerade så att mottagaren kan validera att meddelandet kommer från angiven avsändare samt att det inte förvanskats under transport. Normalt hanteras denna typ av signering/kryptering genom att meddelanden krypteras med hjälp av den publika delen av mottagarens nyckel medan det signeras av den privata delen av avsändarens nyckel.

De största problemen jag har med den beskrivning som gjorts av dagens Mina Meddelanden är  avsaknad av beskrivning av speciellt [4] ovan. Nu när vi i Sverige har sagt oss önska digital signering och nyckelhantering med hjälp av en federationsmodell så visar det att vi har funderat inte så lite på hur detta med nyckelhantering skall gå till för att digitala transaktioner skall kunna ske på ett tillfredsställande sätt.

Naturligtvis måste dessutom alla dessa beskrivningar göras på ett sådant sätt att vi får ett flertal implementationer vad gäller den programvara och de tjänster som krävs för att detta system skall kunna sjösättas.