Kapitel 6. Information til programmører

Dette kapitel indeholder information til de der ønsker at udvikle programmer, der automatiserer de processer, der er beskrevet i de foregående afsnit. Det antages at man vil gøre det som en frontend til openssl programmet og derfor beskrives hvorledes dette kan gøres.

Disse informationer handler udelukkende om at danne en certifikat forespørgsel til KMD-CA.

6.1. Dannelse af certifikat forespørgslen

Man bør sætte sig ind i hvordan req programmet anvendes. Det er en del af openssl programmet. Basalt set kan req lave en x.509 request som den der eftersøges, hvis det gives en række informationer. Den nemmeste måde at få disse informationer videregivet til req er ved at indkode de enkelte parametre i en fil som man giver som config fil til req programmet. Dette er også at foretrække sikkerhedsmæssigt, idet f.eks. password overført via kommandolinjen ikke er hensigtsmæssigt, da de kan ses af andre processer på systemet.

Bemærk, at der pt. er begrænsninger på brugen af æøå ÆØÅ (og andre specialtegn) i forhold til KMD-CA. Kun a-z, A-Z og 0-9 er tilladt.

6.1.1. Eksempel på forespørgselsdannelses fil

Nedenfor gives et eksempel på hvordan en forespørgselskonfigurationsfil til programmet openssl kan se ud. Linjer der starter med tegnet # er kommentarer.


# Eksempel på request config fil.
# Anvendes eksempelvis således:
# openssl req -newkey rsa:1024 -config req.config -out \
# kmd-ca-cert.req -outform DER
# Bemærk at der sættes to password i denne fil, dels et for den
# private nøgle (output_password), dels et challengePassword, som jeg ikke
# rigtigt ved hvad skal bruges til.
# Måske vil man give brugeren adgang til at undlade at sætte
# et password for den private nøgle (vil man???).

# Formatet for denne fil er defineret dels i req(1) og dels i config(1)

# reg sectionen definerer hvordan filen hænger sammen - hvilke øvrige
# sektioner der skal inkluderes mv.
[ req ]
prompt                 = no
default_bits           = 1024
default_md             = sha1

default_keyfile        = keyfile.pem
output_password        = private_key_password

distinguished_name     = req_distinguished_name
attributes             = req_attributes

# Oplysninger om "distinguished name", se f.eks.
# http://docs.iplanet.com/docs/manuals/cms/42/adm_gide/app_dn.htm
# Bemærk, kun felter der medtages i KMD-CA's program er medtaget her
# I KMD's udgave har brugeren kun adgang til at angive givenName,
# surname, email og keyUsage
[ req_distinguished_name ]
C                      = DK
O                      = Ingen organisatorisk tilknytning
CN                     = Joern Guldberg // PID:xxxxxxxxx
emailAddress           = jgu@kmd.dk
givenName              = Joern
surname                = Guldberg
keyUsage               = Digital Signature, Data Encipherment, Key Agreement, Non Repudiation, Key Encipherment
serialNumber           = 9208-2001-1-xxxxxxxxx

# Strengt taget ved jeg ikke om denne sektion er nødvendig
# Faktisk ved jeg ikke hvad den gør. Man siden lægger op til at den
# muligvis ikke er nødvendig overhovedet - afhænger vist lidt
# af vores CA (KMD-CA).
[ req_attributes ]
challengePassword              = tester

Antag at ovenstående er indholdet af filen req.config. Herefter kan man danne en request fil kaldet kmd-ca-cert.req således:


$ openssl req -newkey rsa:1024 \
-config req.config -out kmd-ca-cert.req -outform DER
Using configuration from req.config
Generating a 1024 bit RSA private key
...............................................................++++++
............................................++++++
writing new private key to 'keyfile.pem'
-----
$ ls -l
totalt 20
-rw-rw-r--    1 madsdyd  madsdyd       951 mar 22 08:16 keyfile.pem
-rw-rw-r--    1 madsdyd  madsdyd      1052 mar 22 07:45 req.config
-rw-rw-r--    1 madsdyd  madsdyd       539 mar 22 08:16 kmd-ca-cert.req

Det er filen kmd-ca-cert.req der er forespørgslen, som skal videresendes til KMD-CA.

6.1.2. Beskrivelse af de enkelte felter

I realiteten er det relativt få felter der skal ændres i en request config fil. I det følgende forsøges de relevante felter beskrevet.

  • givenName - personens fornavn (og eventuelle mellemnavne) indsættes her

  • surname - personens efternavn indsættes her

  • emailAddress - personens email adresse indsættes her

  • keyUsage - Se nedenfor i afsnit Afsnit 6.1.2.1

  • CN - værdien af givenName surname appended med strengen "// PID:xxxxxxxxx"

  • serialNumber - dette felt skal ikke ændres når man bruger KMD-CA som CA. Det er beskrevet på en side hos Ministeriet for Videnskab, Teknologi og Udvikling om Personspecifikke Identifikationsnumre .

6.1.2.1. keyUsage

Dette felt sættes efter brugerens valg for hvordan nøglen skal bruges; "Kryptering og digital signatur", "Kun kryptering" eller "Kun signatur". Se Figur 1-1 for de valg Windows programmet giver.

Følgende er baseret på oplysninger fra Jørn Guldberg, projektleder i KMD-CA.

keyUsage sættes til en kommasepareret liste af strenge. For signering sættes "Digital Signatur". For kryptering sættes "Data Encipherment". For begge dele, sættes begge dele. Man skal altid tilføje følgende liste: "Key Agreement, Non Repudiation, Key Encipherment".