ANALYSE VAN http://www.cabforum.org/Baseline_Requirements_V1.pdf

Certificaat uitgifte
M.b.t. de uitgifte van certificaten moet de CA procedures hebben geïmplementeerd en die hebben vastgelegd in haar Certificate Policy en/of Certification Practice Statement voor onder meer de volgende zaken:
1) Vaststellen dat de aanvrager de domainname en/of IP-adres mag gebruiken;
2) Vaststellen dat de persoon die de aanvraag doet daartoe gerechtigd is door de aanvrager;
3) Vaststellen dat de in het certificaat op te nemen gegevens (aangeleverd door aanvrager) correct zijn;
4) Vaststellen dat de inhoud van subject:organizationalUnitName in het certificaat niet misleidend is;
5) Vaststellen van de identiteit van de aanvrager indien het certificaat Subject Identity Information bevat;

Daarnaast:
6) Een juridisch verhaal dat erop neerkomt dat een koper van een certificaat de CA aan deze eisen mag houden;
7) Dat de CA een 24x7 toegankelijke en actuele bron zal bieden voor het opvragen van de status (geldig/ingetrokken) van certificaten;
8) Dat de CA certificaten zal intrekken indien nodig volgens de in het document opgenomen eisen.

Ik zie geen minimumeisen voor de eerstgenoemde 5 procedures. Zo'n procecedure kan dus luiden "check of de persoon blauwe ogen heeft als hij zegt dat hij Jan Jansen heet". Maar goed, in elk geval moet die procedure zijn vastgelegd en in te zien zijn.

Helaas gelden deze regels dus nog niet voor bijv. code signing certificates, alhoewel ik hoop dat Verisign punt 4 voor alle soorten certificaten van toepassing verklaart en niet nog eens een code signing certificaat voor het bedrijf "CLICK YES TO CONTINUE" uitgeeft (zie http://www.benedelman.org/spyware/images/installers-020305.html).

Betrouwbaarheidseisen aan certificaten
Hoewel er, als het goed is, sinds 1-1-2010 geen certificaten met RSA public key lengte kleiner dan 2048 bits uitgegeven mogen worden, kunnen we nog 2 jaar (tot eind 2013) intermediate certificaten met sleutels van 1024 bits lang tegenkomen. En dat is onverstandig, want als een aanvaller zo'n sleutel weet te kraken kan hij voor elke gewenste website certificaten maken terwijl de schade relatief groot is als zo'n certificaat moet worden ingetrokken (en dit er in de praktijk toe leidt dat browserfabrikanten zo'n revoked certificaat in hun expliciete blacklist opnemen). Er wordt al langer gewaarschuwd voor 1024 bit lange RSA sleutels (zie bijv. http://technet.microsoft.com/en-us/library/cc751157.aspx).

Webserver certificaten met een looptijd tot uiterlijk 1-1-2014 mogen nog met 1024 bit lange RSA public key worden uitgegeven, maar hopelijk zul je geen CA meer vinden die z'n handtekening zet onder CSR's (Certificate Signing Requests) waar klanten mee aan komen zetten.

Ik ben nog niet in alle verdere details gedoken, maar opvallend is dat webserver certificaten uitgegeven na 1 april 2015 nog maar maximaal 39 maanden geldig mogen zijn (dat was 60 maanden, en in uitzonderingsgevallen is dat nog mogelijk).

Wildcard certificaten blijven mogelijk (bij EV certificaten kan dat niet).

Eisen aan overeenkomsten met certificaat aanvragers/kopers
In zo'n overeenkomst moet staan dat de aanvrager zich ertoe verplicht en garandeert dat hij alle redelijke maatregelen neemt om als enige toegang te hebben tot de private key, deze geheim zal houden en zal beschermen. In de praktijk doet iedereen dit op z'n eigen manier en komt zo'n CA je echt niet controleren. Daarmee is dit ook een flinke nagel aan de doodskist van PKI; er bestaat geen goed systeem om te detecteren dat een private key door een aanvaller is gekopieerd en wordt misbruikt (vooral bij code signing is dit een belangrijk aspect).

Certificate Revocation and Status Checking
Na ontvangst van een melding dat een private key mogelijk is gecompromitteerd moet de CA binnen 24 uur een onderzoek starten en het certificaat eveneens binnen 24 uur intrekken (het is me niet duidelijk of beide termijnen mogen worden opgeteld, dwz dat het 48 uur kan duren).

Voor webserver certificaten geldt dat CRL's minstens 1x per 7 dagen moeten worden uitgebracht, en het nextUpdate veld mag niet meer dan 10 dagen na het thisUpdate veld zijn.

Voor intermediate CA certificaten geldt CRL's minstens 1x per 12 maanden dagen moeten worden uitgebracht, en het nextUpdate veld mag niet meer dan 12 maanden na het thisUpdate veld zijn. Daarnaast moeten CRL en/of OCSP binnen 24 uur geupdate zijn na het intrekken van zo'n intermediate CA certificaat. Aangezien webbrowsers geen nieuwe CRL ophalen als er een gecachte versie op schijf staat en de nextUpdate datum daarin nog niet bereikt is, lopen gebruikers het risico om een jaar lang een ingetrokken intermediate certificaat te vertrouwen.

Vanaf 1-1-2013 moeten CA's OCSP ondersteunen. Ook interessant is de volgende eis: Onder "normal operating conditions" is dat natuurlijk belachelijk lang. Webbrowsers hebben dan allang de handdoek gegooid (en gaan er in de praktijk vanuit dat alles in orde is als er niet bijtijds antwoord komt). Deze eis sluit dus niet aan op de praktijk.

OPVALLENDE VERSCHILLEN TUSSEN DRAFT EN FINAL VERSIE

- TÜRKTRUST is opgenomen in de lijst met deelnemers;

- Definitie "Certificate" is opgenomen en luidt: "An electronic document that uses a digital signature to bind a public key and an identity";

- Op veel (maar niet alle) plaatsen is het woord "SHALL" vervangen door "MUST" wat als een afzwakking kan worden gezien (er wordt verwezen naar RFC 2119 die beide -helaas- toestaat en er geen onderscheid tussen maakt, maar sommige juristen zullen dit wel doen). Op sommige andere plaatsen is "MUST" door "SHALL" vervangen. Kennelijk hebben een stel juristen aan de laatste versie zitten schaven;

- M.b.t. het Certificate Policy en/of Certification Practice Statement sprak de oude draft versie nog van "display prominently on its Web site", dit is geschrapt in de final versie;

- In v1.0 is, onder Certificate Content and Profile, de optionele "Issuer Domain Component Field", "Subject Domain Component Field" en "Subject Country Field Name" toegevoegd;

- In plaats van dat het recommended is, moeten certificaat serienummers tenminste 20 bits entropie hebben;

- Bij het vaststellen van de identiteit van de aanvrager is het volgende geschrapt: "The CA MAY exercise professional judgment in accepting minor discrepancies, such as common variations and abbreviations". In de plaats daarvan zijn expliciete mogelijkheden voor het vastellen van het adres van de aanvrager opgenomen;

- Verification of Country is opgenomen (op basis van DNS en/of TLD in hostname);

- Geheel nieuw hoofdstuk "12 Certificate Issuance by a Root CA" is tussengevoegd;

- De verplichting om binnen 24 uur updated CRL en/of OCSP data te publiceren na het intrekken van een intermediate CA certificaat is opgenomen;

- "commercially reasonable response time" bij het opvragen van CRL's en OCSP is gewijzigd in "ten seconds or less under normal operating conditions";

- Eis "12.1.5 Root CA CRL 37" is geschrapt: "Certificates issued by a Root CA MUST include the CrlDistributionPoints extension. The URL contained in the 38 CDP extension MUST be publicly accessible.

Oplossing om dit als webmaster te omzeilen: CloudFlare Pro met SSL, dan heb je niet direct met een CA te maken