OCSP Interface versie 1.0 17102007
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
1. Inleiding ESG de electronische signatuur BV 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 FrontEndInterface van een OCSP Responder beschreven. OCSP Interface 2007 Blz. 3
2. De OCSP Responder De basis voor de technische realisering van een OCSP Responder is de ISISMTT specificatie [ISISMTT] 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 ISISMTT een aanvulling tot de internationale gebruikelijke PKIstandaard [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 [ISISMTT]. 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. OCSP Interface 2007 Blz. 4
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}/{urlgecodeerde base64 DERcodeerde 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 DERcodeerde 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 /cgibin/ocsp/mfgwvjbumfiwozajbgurdgmcgguabbqzorkh0+f50398o91ly4xgpscgquagmebqyh CAkQERITFBUWFxgZICECAgOEoBMwETAPBgUrJAgDCQE B%2FwQDAQH%2F<blank>http/1.0 In deze request bestaat de URL uit /cgibin/ocsp. Een aanvraag met de methode POST gebruikt het HTTP Header veld Content_Type met de waarde Application/ocsprequest. De lengte van de aanvraag moet in het HTTP Header veld ContentLength 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 base64codeerd 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 base64dercodeerde aanvraag de ANS.1 structuur OCSPRequest als grondslag ligt: POST {URL} ContentType: Application/ocsprequest ContentLength: {binair of base64der codeerde aanvraag} OCSP Interface 2007 Blz. 5
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 DERcodeerde antwoord de ANS.1 structuur OCSPRequest als grondslag ligt. De transport kan zowel binair of base64gecodeerd plaatsvinden. Het antwoord moet binair gecommuniceerd worden, voor zover het transportmedium het toestaat. In de HTTP Header ContentType moet de waarde Application/ocspresponse aangegeven worden, in de Header ContentLength 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 OCSPRequest 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 [ISISMTT] na te lezen) Request : := SEQUENCE{ reqcert CertID, singlerequestextensions [0] EPLICIT Extensions OPTIONAL } CertID ::= SEQUENCE{ hashalgorithm AlgorithmIdentifier, issuernamehash OCTET STRING, issuerkeyhash OCTET STRING, serialnumber CertificateSerialNumber } OCSP Interface 2007 Blz. 6
2.1.2.2 OCSPResponse 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 [ISISMTT] in ANS.1 standaard ziet als volgt uit (onvolledige weergave van de structuur; volledige beschrijving is in de [ISISMTT] na te lezen): OCSPResponse : := SEQUENCE { responsestatus OCSPResponseStatus, responsebytes [0] EPLICIT 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 trylater. ResponseBytes : := SEQUENCE { responsetype OBJECT IDENTIFIER, response OCTET STRING } idpkixocsp OBJECT IDENTIFIER : := { idadocsp } idpkixocspbasic OBJECT IDENTIFIER : := { idpkixocsp 1 } BasicOCSPResponse : := SEQUENCE { tbsresponsedata ResponseData signaturealgorithm AlgorithmIdentifier, signature BIT STRING, certs [0] EPLICIT SEQUENCE OF Certificate OCSP Interface 2007 Blz. 7
OPTIONAL } ResponseData : := SEQUENCE { Version [0] EPLICIT Version DEFAULT v1, responderid ResponderID, producedat GeneralizedTime, responses SEQUENCE OF SingleResponse, responseextensions [1] EPLICIT Extensions OPTIONAL } ResponderID : := CHOICE { byname [1] EPLICIT Name, bykey [2] EPLICIT KeyHash } KeyHash : := OCTET STRING SingleResponse : :=SEQUENCE { certid CertID, certstatus CertStatus, thisupdate GeneralizedTime, nextupdate [0] EPLICIT GeneralizedTime OPTIONAL, singleextensions [1] EPLICIT Extensions OPTIONAL } CertStatus : := CHOICE { Good [0] EPLICIT 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: IdisismttatcertHash OBJECT IDENTIFIER : := { 1 3 36 8 3 13 } CertHash ::= SEQUENCE { HashAlgorithm AlgorithmIdentifier certificatehash OCTET STRING } OCSP Interface 2007 Blz. 8
2.1.3 Overzicht van de OCSP Protocol Elementen (Sub) Veld ISISMTT genereert geparst analyseert commentaar OCSPRequest tbsrequest tbsrequest optionalsignature Version requestorname requestlist requestextensions moet v1 zijn request reqcert reqcert singlerequestextensions hashalgorithm issuernamehash issuerkeyhash serialnumber Element van requestlist moet bekende OID zijn kan met lengte 0 gecodeerd zijn requestextensions Nonce AcceptableResponses singlerequest Extensions, noncritical, noncritical ServiceLocator May, noncritical wordt transparant aangereikt moet idpkixocspbasic bevatten, indien beschikbaar OCSPResponse responsestatus responsebytes volgens Status responsestatus Succesful malformedrequest internalerror trylater sigrequired unauthorized () () treed niet op, handtekening wordt niet geanalyseerd treed niet op, handtekening wordt niet geanalyseerd responsebytes responsetype response () alleen idpkixocspbasic derhalve BasicResponse response tbsresponsedata signaturealgorithm signature certs altijd SHA1 met RSA bevat certificaten van de complete root responsedata version responderid producedat responses responseextensions altijd v1 OCSP Interface 2007 Blz. 9
(Sub) Veld ISISMTT genereert geparst analyseert commentaar responderid byname bykey altijd byname, onderwerp uit handtekeningcertificaat singleresponse certid certstatus thisupdate nextupdate singleextensions element van responses gelijk aan producedat certstatus revokedinfo good revoked unknown revocationtime revocationreason certhash wordt meegeleverd unknowninfo NULL () revocationreason altijd unspecified responseextension s Nonce CrlID ArchiveCutoff, noncritical, noncritical SHOULD, noncrit alleen als het in de aanvraag beschikbaar is singleextensions CRL entry extensions CertHash CertInDirSince, noncritical, noncritical, noncritical (WEH), alleen met Status = good/revoked alleen met Status = good/revoked OCSP Interface 2007 Blz. 10
3. Literatuurregister [ISISMTT] Common ISISMTT 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. BernersLee: Hypertext Transfer Protocol HTTP / 1.1 Januar 1997 [RFC 2616] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. BernersLee: Hypertext Transfer Protocol HTTP /1.1, Juni 1999 [RFC 2396] T. BernersLee, R. Fielding, U.C. Irvine, L. Masinter, Uniform Resource Identifiers (URI): Generic Syntax, August 1998 [RFC 1945] T.BernersLee, R. Fielding, H. Frystyk: Hypertext Transfer Protocol HTTP / 1.0, May 1996 OCSP Interface 2007 Blz. 11