1

This is how I understand digital signature verification to work in general:

  1. Plaintext gets run through a hashing mechanism to make a message digest (IBM's terminology, there appear to be plenty of other terms for the hashed data).
  2. Message digest is encrypted using sender's private key.
  3. Both encrypted message digest and plaintext are sent to recipient.
  4. Recipient decrypts message digest using sender's public key.
  5. Plaintext gets run through hashing mechanism to make message digest, as in step 1.
  6. If hashed plaintext and decrypted message digest are equivalent, test passes.

What I can't figure out is how this process is specifically applied in RSA verification of a digital certificate. I can't find the plaintext! If it's generated at random for each request, then what's the point of having a digital signature from the assigning CA in the certificate? If it isn't, then where does whoever is verifying the certificate get the plaintext to compare the signature to? I don't see that it's part of the certificate.

So, first, do I understand the general signature verification process as it applies to digital certificate verification? And if I do, can someone solve the "mystery of the missing plaintext" for me?

BobRodes
  • 113
  • 5

1 Answers1

3

Lets fix that description of the signature generation. Please read the PKCS#1 v2.2 specifications to get the full detail.

  1. Canonical binary plaintext gets run through a hashing mechanism to make a message digest (IBM's terminology, there appear to be plenty of other terms for the hashed data).
  2. Message digest is used as input for the configured padding mechanism.
  3. Binary padded message digest is converted to a number.
  4. Number is raised to the power of the private exponent modulo the modulus, either directly or using the Chinese Remainder Theorem.
  5. The number is converted back to binary with the same byte size as the modulus, giving the signature.
  6. Both the plaintext and generated signature are sent to recipient.

As you can see I had to rewrite most of it. The modular exponentiation is commonly seen as the "encryption with private key part", but that's a contradiction in itself; it is just a similar operation and PKCS#1 v2 goes out of the way to explain that. For more information, see my Q/A here.

What I can't figure out is how this process is specifically applied in RSA verification of a digital certificate. I can't find the plaintext!

The certificate contains a to be signed (TBS) part. This can be found in the X.509v3 standard. This is the plaintext in above signature generation scheme:

The signatureValue field contains a digital signature computed upon
the ASN.1 DER encoded tbsCertificate.  The ASN.1 DER encoded
tbsCertificate is used as the input to the signature function.  This
signature value is encoded as a BIT STRING and included in the
signature field.

If it's generated at random for each request, then what's the point of having a digital signature from the assigning CA in the certificate? If it isn't, then where does whoever is verifying the certificate get the plaintext to compare the signature to? I don't see that it's part of the certificate.

It's just data, there are no pointers as in: here is the plaintext within the binary or textual description.

So, first, do I understand the general signature verification process as it applies to digital certificate verification? And if I do, can someone solve the "mystery of the missing plaintext" for me?

Sure see above. But most of this is best found out by reading the standard documents. If you had done that then the mystery would not have existed.

Community
  • 1
Maarten Bodewes
  • 96,351
  • 14
  • 169
  • 323