DNS-certifikatutfärdare

DNS-certifikatutfärdare
Förkortning	CAA
Status	Föreslagen standard
Först publicerad	18 oktober 2010
Senaste versionen	; RFC 8659 november 2019
Organisation	IETF
Författare	Philip Hallam-Baker; Rob Stradling; Jacob Hoffman-Andrews;

DNS Certification Authority Authorization ( CAA ) är en policymekanism för Internetsäkerhet som gör det möjligt för innehavare av domännamn att ange för certifikatutfärdare om de är auktoriserade att utfärda digitala certifikat för ett visst domännamn . Den gör detta med hjälp av en ny "CAA" -resurspost för domännamnssystem (DNS) .

Den utarbetades av datavetarna Phillip Hallam-Baker och Rob Stradling som svar på ökande oro för säkerheten hos offentligt betrodda certifikatmyndigheter. Det är en Internet Engineering Task Force (IETF) föreslagen standard .

Bakgrund

En serie felaktigt utfärdade certifikat från 2001 och framåt skadade förtroendet för offentligt betrodda certifikatmyndigheter och påskyndade arbetet med olika säkerhetsmekanismer, inklusive Certificate Transparency för att spåra felutfärdande, HTTP Public Key Pinning och DANE för att blockera felaktigt utfärdade certifikat på klienten- sida och CAA för att blockera felaktiga utfärdande på certifikatutfärdarens sida.

Det första utkastet till CAA skrevs av Phillip Hallam-Baker och Rob Stradling och lämnades in som ett IETF Internet Draft i oktober 2010. Detta förbättrades successivt av PKIX Working Group och godkändes av IESG som RFC 6844 , en föreslagen standard , i januari 2013. CA/Browser Forum- diskussionen började kort därefter, och i mars 2017 röstade de för att göra CAA-implementering obligatoriskt för alla certifikatutfärdare senast i september 2017. Minst en certifikatutfärdare, Comodo , misslyckades med att implementera CAA före deadline. En studie från 2017 av Münchens tekniska universitet fann många fall där certifikatutfärdare misslyckades med att korrekt implementera någon del av standarden.

I september 2017 skickade Jacob Hoffman-Andrews in ett Internetutkast som syftade till att förenkla CAA-standarden. Detta förbättrades av LAMPS Working Group och godkändes som RFC 8659 , en föreslagen standard, i november 2019.

Från och med januari 2020 rapporterar Qualys att fortfarande bara 6,8 % av de 150 000 mest populära TLS -stödjande webbplatserna använder CAA-poster.

Spela in

Certifikatmyndigheter som implementerar CAA utför en DNS- sökning efter CAA- resursposter , och om några hittas, se till att de är listade som en auktoriserad part innan du utfärdar ett digitalt certifikat . Varje CAA-resurspost består av följande komponenter:

flagga

En flaggbyte som implementerar ett utbyggbart signaleringssystem för framtida användning. Från och med 2018 har endast den kritiska flaggan för utfärdaren definierats, som instruerar certifikatutfärdare att de måste förstå motsvarande egenskapstagg innan de utfärdar ett certifikat. Denna flagga tillåter att protokollet utökas i framtiden med obligatoriska tillägg, liknande kritiska tillägg i X.509-certifikat .

tag

En av följande egenskaper:

issue: Den här egenskapen tillåter innehavaren av domänen som anges i tillhörande egenskapsvärde att utfärda certifikat för domänen för vilken egenskapen är publicerad.
issuewild: Den här egenskapen fungerar som utfärdande men auktoriserar bara utfärdandet av jokerteckencertifikat och har företräde framför utfärdandeegenskapen för begäranden om jokertecken.
iodef: Den här egenskapen anger en metod för certifikatutfärdare att rapportera ogiltiga certifikatförfrågningar till domännamnsinnehavaren med hjälp av Incident Object Description Exchange Format . Från och med 2018 stöder inte alla certifikatmyndigheter denna tag, så det finns ingen garanti för att alla certifikatutfärdanden kommer att rapporteras.
contactemail: I allt högre grad är kontaktinformation inte tillgänglig i WHOIS på grund av oro över potentiella GDPR-överträdelser. Den här egenskapen tillåter domäninnehavare att publicera kontaktinformation i DNS.
kontakttelefon: Som ovan, för telefonnummer.

värde: Värdet som är kopplat till den valda egenskapstaggen.

Avsaknaden av några CAA-poster tillåter normal obegränsad utfärdande, och närvaron av en enda tom etikett förbjuder all utfärdande.

Tredje parter som övervakar certifikatutfärdarens beteende kan kontrollera nyligen utfärdade certifikat mot domänens CAA-poster. RFC 8659 anger; CAA-poster KAN användas av certifikatutvärderare som en möjlig indikator på ett brott mot säkerhetspolicyn. Sådan användning BÖR ta hänsyn till möjligheten att publicerade CAA-poster ändrades mellan det att ett certifikat utfärdades och den tidpunkt då certifikatet observerades av certifikatutvärderaren.

Tillägg

RFC 8657 specificerar "accounturi" och "validationmethods" parametrar som tillåter användare att specificera önskade metoder för domänkontrollvalidering enligt definitionen i ACME-protokollet . Till exempel kan webbplatsadministratören binda en domän som de kontrollerar till ett särskilt konto som är registrerat hos den önskade certifikatutfärdaren.

Historia

Ett utkast till den första förlängningen av CAA-standarden publicerades den 26 oktober 2016 och föreslår ett nytt konto-uri- token till slutet av emissionsegenskapen , som knyter en domän till ett specifikt konto för Automated Certificate Management Environment . Detta ändrades den 30 augusti 2017 för att även inkludera en ny valideringsmetoder- token, som knyter en domän till en specifik valideringsmetod, och ändrades sedan ytterligare den 21 juni 2018, för att ta bort bindestrecket i konto-uri och validering- metoder som gör dem istället accounturi och valideringsmetoder .

Exempel

För att indikera att endast den certifikatutfärdare som identifieras av ca.example.net är auktoriserad att utfärda certifikat för exempel.com och alla underdomäner, kan man använda denna CAA-post:

exempel.com. IN CAA 0 nummer "ca.example.net"

För att inte tillåta utfärdande av certifikat kan man endast tillåta utfärdande till en tom utfärdarlista:

exempel.com. IN CAA 0 nummer ";"

För att indikera att certifikatutfärdare ska rapportera ogiltiga certifikatförfrågningar till en e-postadress och en försvarsslutpunkt mellan nätverk i realtid :

exempel.com. IN CAA 0 iodef "mailto:[email protected]" example.com. IN CAA 0 iodef "http://iodef.example.com/"

För att använda en framtida förlängning av protokollet, till exempel, en som definierar en ny framtida egenskap, som måste förstås av certifikatutfärdaren innan de säkert kan fortsätta, kan man ställa in utfärdarens kritiska flagga:

exempel.com. IN CAA 0 nummer "ca.example.net" example.com. I CAA 128 framtida "värde"

Kända efterlevnadsincidenter

Under 2017 befanns Camerfirma felaktigt validera CAA-register. Camerfirma påstod sig ha missförstått CA/Browser Forum Baseline Requirements som beskriver CAA-validering.

I början av 2020 avslöjade Let's Encrypt att deras programvara felaktigt sökte och validerade CAA-poster som potentiellt påverkar över 3 miljoner certifikat. Let's Encrypt samarbetade med kunder och platsoperatörer för att ersätta över 1,7 miljoner certifikat, men beslutade att inte återkalla resten för att undvika driftstopp för klienten och eftersom alla berörda certifikat skulle förfalla inom mindre än 90 dagar.

Se även

externa länkar

RFC 8659
Lista över CA-identifierare för användning i CAA-poster i Common CA Database