Protokol CMC pro vydávání certifikátů přešel na SHA-256, SHA-1 ale úplně nezmizel

Organizace IETF vydala v červenci 2026 tři dokumenty naráz: RFC 10002, RFC 10003 a RFC 10004. Popisují protokol CMC a ruší platnost RFC 5272, RFC 5273 a RFC 5274 z června 2008 i jejich společného doplňku RFC 6402 z listopadu 2011. Všechny tři jsou v kategorii Standards Track, tedy plnohodnotná norma, ne informativní popis problému.

Čemu CMC slouží

CMC je zkratka za Certificate Management over CMS, tedy správu certifikátů nad syntaxí kryptografických zpráv. Je to protokol, kterým si zařízení vyžádá u certifikační autority certifikát, nechá ho obnovit nebo zneplatnit. Abstrakt RFC 10002 uvádí dvě potřeby, ze kterých protokol vzešel: rozhraní ke službám vydávajícím certifikáty postaveným na CMS a PKCS #10, a zápis klíčů, které umějí jen šifrovat a podepsat samy sebe neumějí.

Rozdělení na tři dokumenty zůstalo stejné jako v roce 2008. RFC 10002 popisuje strukturu zpráv, RFC 10003 způsoby jejich přenosu a RFC 10004 to, co musí implementace umět, aby byla v souladu s normou.

Otisky se posunuly na SHA-256

Nejpodstatnější změnu nese RFC 10004. Jeho vlastní výčet změn proti RFC 5274 a 6402 ji shrnuje třemi odrážkami: SHA-1 nahradil SHA-256, HMAC-SHA-1 nahradil HMAC-SHA-256 a přibyly algoritmy pro AuthEnvelopedData, tedy pro obsah, který je zároveň zašifrovaný a chráněný proti změně.

V podrobnostech to vypadá takhle. Každá strana musí umět ověřit i vytvořit podpis RSA-SHA256, musí podporovat AES jako šifru obsahu a AES-GCM pro obsah šifrovaný s ověřením, a to včetně dvanáctibajtové jednorázové hodnoty i dvanáctibajtového kontrolního součtu. U prvků, kterými žadatel prokazuje totožnost a držení privátního klíče, stojí SHA-256 a HMAC-SHA256 jako povinné.

Kdo provozuje starší implementaci, o spojení nepřijde. RFC 10004 přidalo odstavec o zpětné slučitelnosti: server smí starší algoritmy dál nabízet, ale měl by podle příchozích žádostí zjišťovat, které certifikáty je vhodné převést na bezpečnější.

Přenos vyžaduje aspoň TLS 1.2

RFC 10003 popisuje čtyři cesty, kterými se zprávy CMC dopravují: souborem, elektronickou poštou, přes HTTP a přímo přes TCP. Změny jsou tu drobnější, zato konkrétní. Místo TLS 1.0 se vyžaduje TLS 1.2 nebo novější a implementace se mají řídit doporučeními BCP 195. Při použití TLS 1.3 nebo QUIC je omezené odesílání časných dat (0-RTT), tedy dat poslaných ještě před dokončením ustavení spojení. Omezené je i zřetězení požadavků nad TCP.

Dokument uvádí i registrovaný port: služba se jmenuje pkix-cmc a poslouchá na TCP portu 5318. Novinka roku 2026 to není. Číslo přidělila IANA už kvůli RFC 6402, které ho v roce 2011 popisuje jako registrovaný port; ve výčtu změn RFC 10003 je uvedené proto, že RFC 5273 z roku 2008 ještě žádné přidělené číslo nemělo. Zápis v rejstříku služeb a portů IANA dnes odkazuje na RFC 10003 a nese datum 13. února 2026. Obě RFC ale port zařazují jinam: RFC 6402 mluví o registrovaném rozsahu, RFC 10003 o rozsahu dynamickém a privátním.

Nad tím vším zůstala věta, kterou nové znění přebírá po svém předchůdci: hlavní přepravou pro CMC má i nadále být HTTP.

Klíče, které neumějí podepisovat

Žádost o certifikát musí být podepsaná. Jenže klíč, o jehož certifikát se žádá, podepisovat umět nemusí. Příloha C v RFC 10002 jmenuje Diffieho–Hellmanovu výměnu klíčů, její eliptickou obdobu a mechanismy zapouzdření klíče (KEM) RSA-KEM a ML-KEM. Ten poslední je postkvantový algoritmus, tedy takový, který má odolat i útoku kvantovým počítačem.

Protokol pro ně má náhradní řešení: podpisový algoritmus, který žádný podpis nevytváří (id-alg-noSignature), a k němu dvojici prvků Encrypted POP a Decrypted POP, kterými autorita ověří, že žadatel klíč opravdu drží. Nové vydání k tomu přidalo ukázkovou výměnu zpráv pro certifikát KEM, ve které je odpověď zabalená strukturou KEMRecipientInfo.

Kde SHA-1 v protokolu zůstal

Věta „SHA-1 nahradil SHA-256“ platí pro požadavky na algoritmy, ne pro celý protokol. Starší verze dvou kontrolních prvků mají otisk zadrátovaný: prvek Identity Proof má napevno SHA-1 a HMAC-SHA1, prvek POP Link Witness rovněž. Tabulka souladu v RFC 10004 přitom u POP Link Witness ve staré verzi žádá „MUST“ po registrační i certifikační autoritě, koncovému zařízení ukládá „SHOULD“. Novější POP Link Witness Version 2 se SHA-256 je povinný pro všechny tři role.

Třetí místo je zmíněný podpis, který podpisem není. Hodnota NoSignatureValue obsahuje otisk žádosti spočítaný algoritmem SHA-1 a dokument u ní rovnou píše, že se má ignorovat a že s tímhle typem podpisu není spojená žádná bezpečnost.

Od konceptu k normě to trvalo bezmála dva roky

Obnovu si vzala na starost pracovní skupina LAMPS (Limited Additional Mechanisms for PKIX and SMIME). Podle evidence IETF vyšla nultá revize konceptu draft-ietf-lamps-rfc5272bis 12. září 2024 a poslední, jedenáctá, 26. února 2026. Editory všech tří dokumentů jsou J. Mandel ze společnosti AKAYLA a S. Turner ze sn3rd.

Do nového znění se promítlo i třináct hlášených chyb ve starších dokumentech, které RFC 10002 vypisuje jmenovitě čísly errat.

Pro provoz z toho plyne, že měnit se nemusí nic ze dne na den, protože zpětná slučitelnost zůstala povolená. Kdo ale píše novou implementaci, má od července jednoznačné zadání: SHA-256, AES-GCM a TLS 1.2 nebo novější. A kdo provozuje starou, dostal v RFC 10004 návod, podle čeho přechod načasovat – podle toho, s čím za ním klienti chodí.