2

As I know X.509 self-certificate is a mechanism that the host generates public and private keys, the public key will insert to a certification and the private key will be used to sign the certification. The receiver will verify the certificate by using the public key with certification.

In case if the receiver does not have the algorithm that used to sign the certification, how the receiver can verify the certification?

Does X.509 has default algorithm to sign the certification?

user201635
  • 23
  • 3
  • 1
    I'm pretty sure that if a verifier doesn't understand the signature algorithm (ie cannot verify the signature) it will default to fail validation. – SEJPM Sep 03 '18 at 10:49
  • For a self-signed cert -- that is, a cert that is signed by the same key it contains (not just by the same person or entity) -- the signature is meaningless and useless for security anyway, and may not be checked at all; the cert can only be trusted by other means such as manually. For a non-root cert issued and signed by a CA, this is quite different and verifying the signature is usually vital. – dave_thompson_085 Sep 04 '18 at 02:28

1 Answers1

0

In the latest X.509 RFC you can read:

The signatureAlgorithm field contains the identifier for the cryptographic algorithm used by the CA to sign this certificate. [RFC3279], [RFC4055], and [RFC4491] list supported signature algorithms, but other signature algorithms MAY also be supported.

However from RFC 3279, section 2:

Conforming CAs and applications MUST, at a minimum, support digital signatures and public keys for one of the specified algorithms. When using any of the algorithms identified in this specification, conforming CAs and applications MUST support them as described.

But more importantly, when verifying a certificate chain, there is no need to perform the validation certificate when validating the certificate chain. This certificate needs to be trusted beforehand.

So if you receive the certificate by the appropriate "out-of-band" procedure, you could validate the certificate at that time. Afterwards you only need to validate the dynamic values such as the end date of the certificate and - possibly - the status of the certificate - if it has been revoked or not.

That means that for devices with limited capacity you can validate and verify the certificate beforehand, put it in the device using a trusted path to the device / storage and then "just" check the date in the field.

This can be read in section 6.1 of the X.509 RFC:

When the trust anchor is provided in the form of a self-signed certificate, this self-signed certificate is not included as part of the prospective certification path. Information about trust anchors is provided as inputs to the certification path validation algorithm (Section 6.1.1).

Great, so that solves the problem, right? Not really. The public key of the certificate is commonly also used to encrypt or to verify the signatures send in the application - the reason the certificate exists in the first place. So now you've got your trusted "chain" of one certificate you're stuck with a public key that you cannot use, because it is identical to the one performing the signature verification over the certificate itself.

It would of course be possible that the receiver can encrypt or perform key agreement using the public key while the signature verification algorithm isn't available.

This issue is specific to self signed certificates because the public key is generally only used for a single purpose, while it must at least sign and possibly perform another kind of operation as well.

Notes:

  • Protocols may put additional requirements on which algorithms are supported, e.g. although TLS doesn't explicitly require RSA signatures / encryption, many websites would not work without it.
  • "a certificate" has a different meaning than "a certification". The latter means having a product certified against e.g. FIPS or Common Criteria. So "certification" is normally used in the more analog, paper-y sense.
  • "just" is put within quotation marks because getting the time from a trusted time source may be very tricky on restricted devices.
Community
  • 1
Maarten Bodewes
  • 92,551
  • 13
  • 161
  • 313
  • Nit: no TLS standard requires RSA auth, or even any auth until 1.3 and even then not for PSK, although many (most?) actual uses of TLS especially on the public (hence visible) Web post-Snowden do use RSA auth. – dave_thompson_085 Sep 05 '18 at 01:45