5. Security Considerations

Cette section conserve le texte RFC relatif aux unsigned X.509 certificates, y compris id-alg-unsigned, id-rdna-unsigned, zero-length signatureValue, issuer handling, extension guidance, validation rules, IANA registrations et ASN.1 module.

Texte RFC original

5.  Security Considerations

   It is best practice to limit cryptographic keys to a single purpose
   each.  If a key is reused across contexts, applications risk cross-
   protocol attacks when the two uses collide.  However, in applications
   that use self-signed end entity certificates, the subject's key is
   necessarily used in two ways: the X.509 self-signature and the end
   entity protocol.  Unsigned certificates fix this key reuse by
   removing the X.509 self-signature.

   If an application accepts id-alg-unsigned as part of a certification
   path, or in any other context where it is necessary to verify the
   X.509 signature, the signature check would be bypassed.  Thus,
   Section 4 prohibits this and recommends that applications treat id-
   alg-unsigned the same as any other previously unrecognized signature
   algorithm.  Non-compliant applications risk vulnerabilities analogous
   to those described in [JWT] and Section 1.1 of [JOSE].

   The signature in a self-signed certificate is self-derived and thus
   of limited use to convey trust.  However, some applications might,
   for example, use it as an integrity check to guard against accidental
   storage corruption.  An unsigned certificate does not provide any
   integrity check.  Applications checking self-signature for integrity
   SHOULD instead use some other mechanism, such as an external hash
   that is verified out-of-band.