ESG de electronische signatuur BV

ESG de electronische signatuur BV

OCSP Interface

versie 1.0 17-10-2007

ESG de electronische signatuur BV Inhoudsopgave 1. Inleiding ............................................................................................................................................... 3

2. De OCSP Responder............................................................................................................................. 4 2.1 Het OCSP protocol ......................................................................................................................... 4 2.1.1 http als transport protocol ..................................................................................................... 5 2.1.2 OCSP Data formaten............................................................................................................... 6 2.1.3 Overzicht van de OCSP Protocol Elementen .......................................................................... 9

3. Literatuurregister .............................................................................................................................. 11

OCSP Interface © 2007

Blz. 2

ESG de electronische signatuur BV 1. Inleiding Ter controle van het bestaan en de status van een certificaat is het noodwendig dat u dit kunt navragen bij een vertrouwde instantie. Deze interface van een certificering dienstverlener word in zijn algemeen als registerdienst aangeduid. Het heeft opdracht de gebruiker informatie over de certificaten te verstrekken over een open communicatieverbinding. Hierdoor dient de registerdienst als een vertrouwenswaardige bron voor de controle van certificaten. Te controleren is of certificaten geblokkeerd zijn of niet. Deze dienst wordt software technisch door een LDAP server (Lightweight Directory Access Protocol Server) en een OCSP Responder (Online Certificate Status Protocol Responder) gerealiseerd. In dit document wordt de functie en de Front-End-Interface van een OCSP Responder beschreven.


Blz. 3

ESG de electronische signatuur BV 2. De OCSP Responder De basis voor de technische realisering van een OCSP Responder is de ISIS-MTT specificatie [ISIS-MTT] De OCSP Responder verricht de volgende taken: Acceptatie en syntactische analyse van aanvragen aan de OCSP Responder Beschikbaar stellen van statusinformatie van Handtekening- Encryptie- en Attribuutcertificaten Tot stand brengen van gecodeerde antwoorden. In deze antwoorden word de wettelijke geldige tijd ingebonden Digitale handtekening van dit gegenereerde gegevenspakket d.m.v. een privé sleutel. Deze privé sleutel is aan een handtekeningcertificaat gekoppeld die de registerdienst van de ZS authentiseerd. Terugkoppeling van de antwoorden aan de gebruikers Tot stand brengen van foutmeldingen bij problemen

De WEH (Wet Electronische Handtekening) vereist van de registerdienst geaccrediteerde certificaat dienstverlener naast informatie over de intrekking van certificaten een zogenoemde positiefuitkomst, die meld of een certificaat in het register voor handen is. Om aan deze wettelijke vorderingen te voldoen, werd in het kader van de standaardisering ISIS-MTT een aanvulling tot de internationale gebruikelijke PKIX-standaard [RFC 2560] in de vorm van een privé extensie (CertHash als positiefstatement) in de OCSP Responder gedefinieerd.

2.1 Het OCSP protocol Alle aanvragen aan een OCSP server worden met behulp van het http protocol overgedragen en moeten in een gedefinieerd formaat beschikbaar zijn (OCSP request). Zie hier voor ook [ISIS-MTT]. De aanvragen hoeven niet digitaal ondertekent te zijn. Het antwoord van de OCSP Responder levert voor elk WEH certificaat alsmede encryptie en attribuut certificaat, nadat deze is aangevraagd, één van de volgende drie informatie statussen: Het certificaat is niet ingetrokken en in het register beschikbaar Het certificaat is ingetrokken Het certificaat bevindt zich niet in de lijst van de uitgestelde certificaten gepubliceerd door de certificaat dienstverlener

In de antwoorden van de OCSP Responder aan de klant wordt telkens de geldige wettelijke tijd ingebonden. Op grond van een specificatie van de BSI gebeurt er bij foutmeldingen alleen de aangifte van de overeengekomen foutcode zonder ingebonden tijdstempels. Zonder zekerheid van de integriteit van het antwoord alsmede zonder zekerheid van de identiteit van de uitgever wordt het antwoord met behulp van een privé sleutel digitaal ondertekend. Het bijbehorende handtekeningcertificaat van de registerdienst wordt bij het antwoord bijgevoegd. Om meerdere aanvragen parallel te kunnen beantwoorden, beschikt de OCSP Responder over meerdere DIR chipkaarten met de gepaste handtekeningsleutel certificaten.


Blz. 4

ESG de electronische signatuur BV 2.1.1 http als transport protocol In dit hoofdstuk wordt op het inbedden van OCSP aanvragen en antwoorden in HTTP ingegaan. De communicatie van transport van OCSP aanvragen over HTTP vindt plaats over de beschreven dataformaten, die als berichten over het Hypertekst Transfer Protocol (HTTP) aan de OCSP Responder overgebracht worden. Het gebruik over HTTP [RFC2068] staat een simpele vervaardiging van software toe voor toegang op registerdiensten van het gebruik van betrouwbare programmabibliotheken.

2.1.1.1 Definities voor de aanvragen HTTP gebaseerde OCSP aanvragen kunnen ofwel de HTTP toegangsmethode “Get” of “Post” gebruiken, waarbij aanvragen de lengte van meer dan 254 Bytes hebben, aansluitend met de methode “Post” aan de registerdienst overgedragen moeten worden. De registerdienst moet aanvragen van de beide methodes kunnen verstaan en verwerken. Aanvragen aan de registerdienst met de toegangsmethode GET gebruiken het volgende formaat, waarbij de base64 DER gecodeerde aanvraag de ASN.1 structuur OCSPRequest als grondslag ligt: GET {url}/{url-gecodeerde base64 DER-codeerde aanvraag} De te gebruiken URL moet de lokale configuratie van de klant ontnomen worden of over andere wegen gecommuniceerd worden.

Aanwijzing: de base64 weergave van de DER-codeerde aanvraag bevat normaliter ook slashes ( / ), plus- ( + ) en gelijktekens ( = ). Deze zijn binnen de URL syntax als speciale tekens te behandelen, die vermeden moeten worden. Dit gebeurt door het vervangen van iedere slash door %2F, iedere plus door %2B en ieder gelijkteken door %3D. Hierbij handelt het zich om de ASCII weergave van de hexadecimale waardes van de ASCII waardes van ieder speciaal teken; deze weergave wordt nog een procent teken vooropgesteld. Deze codering is gedefinieerd en gestandaardiseerd door [RFC2616] en [RFC2396]. Aanwijzing: omdat voor de OCSP R alleen de request na de laatste slash interessant is, worden alleen de drie getoonde tekens gedecodeerd, omdat ze alleen binnen de Base64 codering kunnen voorkomen.

Voorbeeld: GET /cgi-bin/ocsp/MFgwVjBUMFIwOzAJBgUrDgMCGgUABBQzoRkh0+f50398o91Ly4xGpSXcXgQUAgMEBQYH CAkQERITFBUWFxgZICECAgOEoBMwETAPBgUrJAgDCQE B%2FwQDAQH%2Fhttp/1.0 In deze request bestaat de URL uit “/cgi-bin/ocsp”. Een aanvraag met de methode POST gebruikt het HTTP Header veld “Content_Type” met de waarde “Application/ocsp-request”. De lengte van de aanvraag moet in het HTTP Header veld “Content-Length” met de lengte van de inhoud van de HTTP aanvraag bewezen worden. Als inhoud van de HTTP aanvraag word de DERcodeerde aanvraag aan de registerdienst toegepast. Aanvragen met de methode POST kunnen ofwel binair of base64-codeerd plaatsvinden. De aanvraag moet binair gecommuniceerd worden, voor zover het transport medium dit toestaat. Registerdiensten moet beide coderingen kunnen verwerken. Aanvragen bij de registerdienst met de toegangsmethode POST gebruiken de volgende formaten, waarbij de base64-DERcodeerde aanvraag de ANS.1 structuur OCSPRequest als grondslag ligt: POST {URL} Content-Type: Application/ocsp-request Content-Length: … {binair of base64-DER codeerde aanvraag}


Blz. 5

ESG de electronische signatuur BV Buiten de hier uitgevoerde HTTP Header velden worden er geen verdere velden gebruikt, maar alleen stilzwijgend genegeerd. De OCSP R gedraagt zich desbetreffend als een HTTP/1.0 server (zie [RFC 1945], Bijlage D).

2.1.1.2 Definities voor de antwoorden Een HTTP antwoord bestaat uit de gebruikelijke HTTP Header, de inhoud van het document is het DERcodeerde antwoord, waarbij het DER-codeerde antwoord de ANS.1 structuur OCSPRequest als grondslag ligt. De transport kan zowel binair of base64-gecodeerd plaatsvinden. Het antwoord moet binair gecommuniceerd worden , voor zover het transportmedium het toestaat. In de HTTP Header “Content-Type” moet de waarde “Application/ocsp-response” aangegeven worden, in de Header “Content-Length” zou de lengte van het volgende document aangegeven moeten worden. Andere HTTP Headers kunnen beschikbaar zijn en kunnen door de gebruikersinfrastructuur genegeerd worden.

2.1.2 OCSP Data formaten 2.1.2.1 OCSP-Request Een WEH conforme registerdienst staat het afroepen van status informatie van certificaten toe en van afroepbare certificaten zelf. Voor de afroep wordt door de aanvragende applicatiegebruiker de volgende genoemde informatie aan de registerdienst overgedragen: Informatie over de te gebruiken Hashalgoritmen (Hashalgorithm) Informatie over de naam van de ondertekenaar (issuerNameHash) Informatie over het resultaat van de toepassing van de hashfunctie op de waarde van het veld subjectPublicKey (zonder de ANS.1 en de lengtebeschrijving) uit het certificaat van de ondertekenaar (issuerKeyHash) Informatie over het serienummer van het desbetreffende certificaat (serialNumber)

De formele structuur van de aanvraag in de ANS.1 standaard ziet als volgt uit (Onvolledige weergave van de structuur; volledige beschrijving is in de [ISIS-MTT] na te lezen) Request : := SEQUENCE{ reqCert CertID, singleRequestExtensions [0] EXPLICIT Extensions OPTIONAL }

CertID : := SEQUENCE{ hashAlgorithm AlgorithmIdentifier, issuerNameHash OCTET STRING, issuerKeyHash OCTET STRING, serialNumber CertificateSerialNumber }


Blz. 6

ESG de electronische signatuur BV 2.1.2.2 OCSP-Response De antwoorden van de registerdienst worden aan de applicatiegebruiker terug gestuurd. Het antwoord van de dienst kan voor ieder certificaat principieel drie verschillende resultaten leveren. De antwoorden dragen een gekwalificeerde handtekening, bevatten het tijdstip van het antwoord (Tijdstempel) en de statusinformatie. Is het opgevraagde certificaat in de databank beschikbaar en niet ingetrokken, Luid de bijbehorende statusinformatie “good” Is het opgevraagde certificaat in de databank beschikbaar en ingetrokken, luid de bijbehorende statusinformatie “revoked” Is het opgevraagde certificaat niet in de databank beschikbaar, luid de bijbehorende statusinformatie “unknown”

De resultaatmeldingen van de OCSP registerdienst luiden: Naam successful malformedRequest internalError tryLater

Omschrijving Succesvolle verwerking van een aanvraag Geen succesvolle verwerking van de aanvraag wegens foutief aanvraag formaat Optreden van een interne fout in de registerdienst Tijdelijke onbeschikbaarheid van de registerdienst

Ondertekende aanvragen worden niet ondersteunt; de handtekeningen worden niet geanalyseerd. De formele structuur van het antwoord volgens [ISIS-MTT] in ANS.1 standaard ziet als volgt uit (onvolledige weergave van de structuur; volledige beschrijving is in de [ISIS-MTT] na te lezen): OCSPResponse : := SEQUENCE { responseStatus OCSPResponseStatus, responseBytes [0] EXPLICIT ResponseBytes OPTIONAL } OCSPResponseStatus : := ENUMERATED { succesful (0), malformedRequest (1), internalError (2), tryLater (3), sigRequired (5), unauthorized (6) } Mogelijke foutwaardes van een antwoord zijn malformedRequest, internelError en try-Later. ResponseBytes : := SEQUENCE { responseType OBJECT IDENTIFIER, response OCTET STRING } id-pkix-ocsp OBJECT IDENTIFIER : := { id-ad-ocsp } id-pkix-ocsp-basic OBJECT IDENTIFIER : := { id-pkix-ocsp 1 } BasicOCSPResponse : := SEQUENCE { tbsResponseData ResponseData signatureAlgorithm AlgorithmIdentifier, signature BIT STRING, certs [0] EXPLICIT SEQUENCE OF Certificate


Blz. 7

ESG de electronische signatuur BV OPTIONAL } ResponseData : := SEQUENCE { Version [0] EXPLICIT Version DEFAULT v1, responderID ResponderID, producedAt GeneralizedTime, responses SEQUENCE OF SingleResponse, responseExtensions [1] EXPLICIT Extensions OPTIONAL } ResponderID : := CHOICE { byName [1] EXPLICIT Name, byKey [2] EXPLICIT KeyHash } KeyHash : := OCTET STRING SingleResponse : :=SEQUENCE { certID CertID, certStatus CertStatus, thisUpdate GeneralizedTime, nextUpdate [0] EXPLICIT GeneralizedTime OPTIONAL, singleExtensions [1] EXPLICIT Extensions OPTIONAL } CertStatus : := CHOICE { Good [0] EXPLICIT NULL, Revoked [1] IMPLICIT RevokedInfo, Unknown [2] IMPLICIT UnknownInfo } Extensions : := SEQUENCE { extnId OBJECT IDENTIFIER critical BOOLEAN DEFAULT FALSE extnValue OCTET STRING } Volgende extensie wordt gebruikt om het positief resultaat weer te geven: Id-isismtt-at-certHash OBJECT IDENTIFIER : := { 1 3 36 8 3 13 } CertHash ::= SEQUENCE { HashAlgorithm AlgorithmIdentifier certificateHash OCTET STRING }


Blz. 8


request reqCert

reqCert singleRequestextensions hashAlgorithm issuerNameHash issuerKeyHash serialNumber

MAY MAY MUST

MUST

X X X X X X

X X X X

X X X X X X

X X X X X X

Element van requestList

wordt transparant aangereikt moet id-pkix-ocsp-basic bevatten, indien beschikbaar

requestExtensions

Nonce AcceptableResponses

MAY, non-critical MAY, non-critical

X X

X X

singleRequestExtensions

ServiceLocator

May, non-critical

X

X

OCSPResponse

responseStatus responseBytes

MAY

X X

Succesful malformedRequest internalError tryLater sigRequired

MUST MUST MUST MUST MUST

X X X X (X)

unauthorized

MUST

(X)

responseBytes

responseType response

(MUST) MUST

X X

response

tbsResponseData signatureAlgorithm signature certs

MAY

X X X X

MAY

X X X X X

responseStatus

responseData

version responderID producedAt responses responseExtensions


commentaar

analyseert

tbsRequest

tbsRequest optionalSignature Version requestorName requestList requestExtensions

geparst

OCSPRequest

genereert

ISIS-MTT

(Sub-) Veld

2.1.3 Overzicht van de OCSP Protocol Elementen

moet v1 zijn

moet bekende OID zijn kan met lengte 0 gecodeerd zijn

volgens Status

treed niet op, handtekening wordt niet geanalyseerd treed niet op, handtekening wordt niet geanalyseerd alleen id-pkix-ocsp-basic derhalve Basic-Response

altijd SHA1 met RSA bevat certificaten van de complete root altijd v1

Blz. 9

singleResponse

certStatus

revokedInfo

unknownInfo

singleExtensions

commentaar

MAY

X

byKey

MAY

element van responses

MAY MAY

X X X X

certHash wordt meegeleverd

certID certStatus thisUpdate nextUpdate singleExtensions

gelijk aan producedAt

MAY

X X X X X

NULL

(MUST)

X

MAY

X

altijd “unspecified”

Nonce

MAY, non-critical

X

alleen als het in de aanvraag beschikbaar is

CrlID ArchiveCutoff

MAY, non-critical SHOULD, non-crit

X

CRL entry extensions CertHash

MAY, non-critical MAY, non-critical

X

CertInDirSince

MAY, non-critical

X


MUST MUST MUST

altijd byname, onderwerp uit handtekeningcertificaat

good revoked unknown revocationTime revocationReason

revocationReason responseExtension s

analyseert

byName

geparst

genereert

responderID

ISIS-MTT

(Sub-) Veld


MUST (WEH), alleen met Status = good/revoked alleen met Status = good/revoked

Blz. 10

ESG de electronische signatuur BV 3. Literatuurregister [ISIS-MTT] Common ISIS-MTT Specification fpr PKI Applications, from T7 & TeleTrusT Version 1.0.2 [RFC 2560] M. Myers, R. Ankney, A. Malpani, S. Galperin, C. Adams, Online Certificate Status Protocol – OCSP, June 1999 [RFC 2068] R. Fielding, J. Getting, J. Mogul, H. Frystyk, T. Berners-Lee: Hypertext Transfer Protocol – HTTP / 1.1 Januar 1997 [RFC 2616] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee: Hypertext Transfer Protocol - HTTP /1.1, Juni 1999 [RFC 2396] T. Berners-Lee, R. Fielding, U.C. Irvine, L. Masinter, Uniform Resource Identifiers (URI): Generic Syntax, August 1998 [RFC 1945] T.Berners-Lee, R. Fielding, H. Frystyk: Hypertext Transfer Protocol - HTTP / 1.0, May 1996


Blz. 11

ESG de electronische signatuur BV

Recommend Documents