Quelles propriétés d'un certificat X.509 doivent être critiques et lesquelles ne le sont pas?
RFC5280 section 4.2 états
Chaque extension d'un certificat est désignée comme critique ou non critique. Un système utilisant un certificat DOIT rejeter le certificat s'il rencontre une extension critique qu'il ne reconnaît pas ou une extension critique qui contient des informations qu'il ne peut pas traiter. Une extension non critique PEUT être ignorée si elle n'est pas reconnue, mais DOIT être traitée si elle est reconnue.
mais je ne trouve pas d'informations (de préférence une courte liste) sur quelles extensions devraient (pas) être désignées comme critiques. J'ai rencontré le basicConstraints pour être critique, à la fois parce qu'il est basique et parce qu'un certificat marqué comme CA:FALSE ne devrait évidemment pas être en mesure de signer des certificats enfants (bien que je pense avoir lu quelque part que pathlen pour les autorités de certification restreintes semble être ignoré occasionnellement) - mais c'est aussi l'une des parties les plus élémentaires d'un certificat, qui C'est probablement pourquoi il est souvent non désigné critique. keyUsage semble être un bon candidat pour la critique, mais qu'en est-il de extendedKeyUsage et subjectAltName?
Existe-t-il un bref aperçu indiquant quelles extensions doivent être a) critiques b) non critiques c) n'a pas d'importance?
Dans "X.509 pur", peu importe qu'une extension soit critique ou non, car les implémentations conformes sont censées honorer les extensions qu'elles reconnaissent, qu'elles soient marquées comme critiques ou non. L'indicateur "critique" est pour les extensions qui sont pas standard: vous rendez une telle extension critique si elle est importante pour la sécurité (les implémentations qui ne comprennent pas l'extension doivent rejeter le certificat), ou non -critique sinon (les implémentations qui ne comprennent pas l'extension peuvent alors l'ignorer en toute sécurité).
Il existe une légère exception à cette règle, avec l'extension CRL Distribution Points. Il a deux objectifs: documenter d'où la CRL peut être téléchargée et implémenter la segmentation de la portée . Ce dernier rôle n'est actif que lorsque l'extension est critique. Lorsque l'extension est critique, une CRL peut être considérée comme couvrant le certificat (c'est-à-dire pour pouvoir dire quelque chose sur son état de révocation) uniquement si la CRL contient une extension Issuing Distribution Point, Avec un "point de distribution" qui correspond à l'une de celles spécifiées dans l'extension CRL Distribution Point du certificat. Lorsque l'extension n'est pas critique, l'extension ne sert que dans son rôle de documentation.
En pratique , vous rendrez les extensions critiques ou non selon qu'elles peuvent être ignorées sans percer un trou trop gros dans toute la sécurité, et aussi en fonction de si le fait de rendre l'extension critique induira les implémentations existantes à rejeter le certificat par manque de support. Par exemple, si vous utilisez une extension critique Name Constraints, Vous risquez un rejet inconditionnel des anciennes versions d'OpenSSL (les versions antérieures à 1.0, qui sont toutes en fin de vie, ne la prennent pas en charge); mais si vous le rendez non critique, alors le même OpenSSL l'ignorera . L'extension Name Constraints Est un cas typique d'une extension qui ne peut pas être ignorée en toute sécurité, et doit donc toujours être marquée comme critique (mais problèmes d'interopérabilité rendre son utilisation potentiellement problématique).
RFC 528 répertorie, pour chaque extension de certificat, si une autorité de certification conforme doit rendre l'extension critique ou non. Ce sont des exigences sur l'AC et non sur des valideurs; un système qui valide un certificat ne doit pas le rejeter au motif qu'il inclut une extension critique Subject Key Identifier, même si la RFC 5280 dit (section 4.2.1.2):
Les AC conformes DOIVENT marquer cette extension comme non critique.
Consultez le RFC pour les détails sur chaque extension: ce sont des directives sur le comportement de votre autorité de certification. Par exemple, Key Usage Est un "DEVRAIT être critique", Basic Constraints Est un "PEUT être critique", Name Constraints Est un "DOIT être critique", etc. Si vous suivez ces règles, votre sécurité ira bien (mais vous devrez peut-être apporter quelques modifications pour l'interopérabilité).