Ad "Certificate policies se totiž můžou chovat „kvantově“: mějme certifikát s rozšířením certificate policies, které je označené jako critical. Je klidně možné, že ze dvou TLS klientů jeden daný certifikát nepřijme a druhý ano – přitom u obou to může být korektní chování. Viděl jsem to i naživo u Chrome a Firefoxu, jednalo se o korejskou CA (certifikáty mezitím obměnili, ale mám je uložené). Trik je v tom, že rozšíření je označeno jako „critical“. To značí, že pokud mu klient rozumí, pak se podle něj musí chovat a pokud mu nerozumí, musí ohlásit chybu validace."
A jak by se to mělo chovat jinak? Když je rozšíření kritické, je správně, že klient ohlásí chybu a odmítne pokračovat, pokud ho nepodporuje. Představte si třeba, že CA má v kritickém rozšíření napsáno, že smí vydávat certifikáty jen pro .cz doménu, nebo třeba jen .nejaka-firma.cz -- kdyby prohlížeč toto rozšíření ignoroval, protože mu nerozumí, byl by to velký průšvih, protože by nějaká CA důvěryhodná pro danou (sub)doménu mohla podepisovat certifikáty komukoli.
Na omezení DNS jmen třeba na .cz nebo nejaka-firma.cz slouží X.509 extension name constraints, která je mnohem jednodušší než certificate policies. Velké browsery name constraints podporují.
Vyhození chyby na nerozeznanou extension označenou jako critical je samozřejmě správně. Jak se má chovat TLS klient, pokud označená critical není a má špatnou ASN.1 syntax, už definováno není. OpenSSL je třeba dost permisivní pokud se zaměňujou některé věci jako typy řetězců (např. BMPString nebo UTF8String místo vyžadovaného IA5String).
HARICA měla nějaké testovací servery s name constraints, ale zdá se, že už nejsou v provozu: https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/5v-yMBII6Mw/EB1QEytGne8J
Ad "Vyhození chyby na nerozeznanou extension označenou jako critical je samozřejmě správně."
V tom případě moc nechápu, na co si daný odstavec stěžuje a jaký je jeho smysl.
Ad "Jak se má chovat TLS klient, pokud označená critical není a má špatnou ASN.1 syntax, už definováno není."
Definováno to je:
"A certificate-using system MUST reject the certificate if it encounters a critical extension it does not recognize or a critical extension that contains information that it cannot process. A non-critical extension MAY be ignored if it is not recognized, but MUST be processed if it is recognized."
Pokud je tam špatný datový typ, tak to buď "nerozpoznáme" (a pak to můžeme ignorovat) nebo to rozpoznáme a zpracujeme a součástí toho zpracování je zotavení se z chyb nebo konverze typu případně zamítnutí... každopádně je to v kompetenci dané aplikace.
Není na tom nic záhadného ani nepředvídatelného. Prostě když posílám nekritické rozšíření, které druhá strana nemusí podporovat nebo ho posílám špatně zakódované, musím počítat s tím, že se možná nezpracuje.
Nejde vysloveně o "critical", ta část je zrovna celkem jednoduchá.
Neexistuje ale jediný TLS klient, který by plně nebo alespoň korektně implementoval RFC 5280. Jenom k path validation je další RFC 4158, které si opět různé implementace vykládájí různě.
MS CryptoAPI dělá třeba "AIA chasing" kdy si stáhne odněkud certifikáty CA uvedené v Authority Information Access, nahradí nimi původní certifikáty v řetězci - a tam třeba můžou klidně být úplně jiné extensions.
Hledání cesty v grafu při validaci certifikátů může klidně vrátit pro jeden certificate chain poslaný od serveru třeba 16 různých možných cest (některé jsou důsledkem toho AIA chasing, jiné důsledkem cross-certification, možných příčin je dost).
Dovolím si tvrdit, že neexistuje nikdo, kdo dokáže předvídat a ošetřit všechny případy v kódu a to ani kdyby TLS klienti implementovali RFC přesně (což se nikdy nestane).
Jeden z těch korejských certifikátů (zde zrovna policy není critical), ale chci na tom ukázat "speciální" případ: http://pastebin.com/yNxr9vu4
CRL URI má jenom ldap:// schému - nenašel jsem zatím běžně používaného TLS klienta, který by CRL přístup přes LDAP implementoval. OCSP v Authority Information Access není. Je tam jenom CA issuers, které je opět přístupné jenom LDAPem.
Prakticky je tento certifikát nerevokovatelný: OCSP nepodporuje a CRL si žádný klient nestáhne.
gnupg2 řeší politiky tak, že si je uživatel může explicitně vyjmenovat. Popravdě gnupg2 umí stahovat CRL i přes LDAP. Ale zas je tam celá řada jiných chyb (třeba neumí částečné CRL).
