PKI Resource Query Protocol
PKI Resource Query Protocol ( PRQP ) är ett Internetprotokoll som används för att få information om tjänster som är associerade med en X.509 Certificate Authority . Den beskrivs av RFC 7030 publicerad den 23 oktober 2013. PRQP syftar till att förbättra interoperabilitets- och användbarhetsproblem mellan PKI:er, och hjälper till att hitta tjänster och datalager som är associerade med en CA. Meddelanden som kommuniceras via PRQP är kodade i ASN.1 och kommuniceras vanligtvis över HTTP .
Bakgrund
För närvarande definieras allt fler tjänster och protokoll för att möta olika behov hos användare och administratörer i PKI:er. Med utbyggnaden av nya applikationer och tjänster är behovet av att komma åt PKI-resurser som tillhandahålls av olika organisationer avgörande. Varje applikation måste berättas om hur man hittar dessa tjänster för varje nytt certifikat den stöter på. Därför måste varje applikation konfigureras korrekt genom att fylla i komplexa konfigurationsalternativ vars innebörd mestadels är okänd för den genomsnittliga användaren (och sannolikt även för administratören).
Relaterade metoder
I PKI:er finns det tre andra primära metoder för klienter att få pekare till PKI-data: anta specifika certifikattillägg ; titta på lättillgängliga arkiv (t.ex. DNS, lokal databas, etc.); och anpassning av befintliga protokoll (t.ex. Web Services ) .
Certifikatförlängningar
För att ge pekare till publicerade data kan en CA använda tilläggen Authority Information Access (AIA) och Subject Information Access (SIA) som beskrivs i RFC 3280 . Den förra kan ge information om utfärdaren av certifikatet medan den senare bär information (inuti CA-certifikat) om erbjudna tjänster. Subject Information Access- tillägget kan bära en URI för att peka på certifikatarkiv och tidsstämplingstjänster. Detta tillägg tillåter därför åtkomst till tjänster med flera olika protokoll (t.ex. HTTP , FTP , LDAP eller SMTP ).
Även om det uppmuntras är användningen av AIA- och SIA-tilläggen fortfarande inte allmänt utplacerad. Det finns två huvudorsaker till detta. Den första är bristen på stöd för sådana tillägg hos tillgängliga klienter. Det andra skälet är att tillägg är statiska, dvs inte modifierbara. Faktum är att för att ändra eller lägga till nya tillägg, för att användare och applikationer ska vara medvetna om nya tjänster eller avskedande av dem, måste certifikatet utfärdas på nytt.
Detta skulle inte vara möjligt för End Entities (EE)-certifikat, förutom vid periodisk återutgivning, men det skulle vara möjligt för själva CA-certifikatet. CA kan behålla samma publika nyckel och namn och bara lägga till nya värden till AIA-tillägget i det nya certifikatet. Om användare hämtar CA-certifikatet regelbundet, istället för att cache det, skulle detta göra det möjligt för dem att bli medvetna om de nya tjänsterna. Även om detta är möjligt söker nästan alla tillgängliga klienter inte efter CA-certifikat om de redan är lagrade i klienternas lokala databas.
I vilket fall som helst, eftersom webbadresser tenderar att ändras ganska ofta medan certifikat kvarstår under längre tidsramar, tyder erfarenheten på att dessa tillägg alltid pekar på webbadresser som inte längre existerar. Dessutom, med tanke på det faktum att enheten som utfärdar certifikaten och den som driver tjänsterna kanske inte är densamma, är det omöjligt att den utfärdande CA kommer att återutge hela sitt certifikat om en server-URL ändras. Därför är det inte klokt att vara beroende av användningen av AIA- eller SIA-tillägg för att söka efter tillgängliga tjänster och arkiv.
DNS Service Records
Tekniken för SRV-posten eller DNS Service-posten anses ge pekare till servrar direkt i DNS (RFC 1035). Enligt definitionen i RFC 2782 tillåter introduktionen av denna typ av post administratörer att utföra operationer som är ganska likna de som behövs för att lösa problemet med PRQP-adresser, dvs en lätt konfigurerbar PKI-upptäcktstjänst.
Grundidén är att låta klienten fråga DNS för en specifik SRV-post. Till exempel, om en SRV-medveten LDAP-klient vill upptäcka en LDAP-server för en viss domän, utför den en DNS-sökning för _ldap._tcp.example.com ( _tcp betyder att klienten begär en TCP -aktiverad LDAP- server). Den returnerade posten innehåller information om prioritet, vikt, port och målet för tjänsten i den domänen.
Problemet med antagandet av denna mekanism är att det i PKI:er (till skillnad från DNS) vanligtvis inte finns några fasta krav på namnutrymmet som används. För det mesta finns det ingen överensstämmelse mellan DNS-struktur och data i certifikaten. Det enda undantaget är när Domain Component (DC) används i certifikatets Ämne .
DC-attributen används för att specificera domänkomponenter i ett DNS-namn, till exempel kan domännamnet example.com representeras med formatet dc=com, dc=example . Om CA:s ämnesfält skulle använda ett sådant format, skulle Emittentfältet tillåta klientapplikationer att utföra DNS-sökningar för den tillhandahållna domänen där informationen om arkiv och tjänster kan lagras.
Men för närvarande är praxis väldigt annorlunda. Faktum är att det är extremt svårt för en klient att mappa digitala certifikat till DNS-poster eftersom DC-formatet inte är allmänt antaget av befintliga certifikatutfärdare. Till exempel använder endast ett certifikat från IE7/Outlook-certifikatarkivet domänkomponenterna för att tillhandahålla en mappning mellan certifikatet och en Internetdomän.