11

Based on this question, I'm interested in any rational argument that would support the idea of maintaining separate signing and authentication certificates.

Conventional logic & wisdom says there is no need to separate an Identity and Signing certificate, but I'm looking for any rational reason to the contrary (devil's advocate).

Here are a few imaginary examples that might have a basis in IT operations, risk management, or separation of concerns. I hope that someone will validate any of these reasons (or will come up with their own) that justify separate keys:

Possible examples:

  1. Is there any need to have different lifetimes/expiration of authentication and signing certs?
  2. Is there ever a need to have different assurance levels of each certificate? (different CAs?)
  3. Is it plausible that I need to revoke one, and not the other? Why?
  4. Are there different software workflows, based on key usage (EKU) that would discourage automated operation? (preventing viruses from authenticating or signing as you)
  5. Should I defend from Non-technically savvy legislation that may require such separation in the future? (Security theatre)
  6. Do they have different storage requirements (smart card, trusted device, DPAPI, etc) for multiple devices? (Do I need the same or different cert on a Phone, PC, iPad)
  7. If multiple valid signing and identity certs are "active" at a time, does that help isolate and partition risk of misuse (all offending usages can be contained)?
  8. ...?

These are a few ideas that I can think of that might justify the need to maintain different signing keys, but I'm unsure of how realistic they are (including stuff I haven't thought of).

From a technical perspective I can imagine needing separate keys for these (and possibly other reasons)

  1. Limitations on algorithm RSA vs ECC
  2. key length
  3. Internal compatibility (SHA1/SHA2/SHA3)
Community
  • 1
makerofthings7
  • 50,090
  • 54
  • 250
  • 536

2 Answers2

5

The EBICS financial protocol (European alternative to SwiftNet) can be a pertinent real life example. It uses three certificates respectively for authentication, signature and encryption.

Most (if not all) banks use three different certificates. However the official protocol specifications allows the use of the same certificate for authentication and encryption, but requires the use of a separate certificate dedicated exclusively to signature:

EBICS allows the use of three different key pairs per subscriber. In doing this, EBICS promotes the use of at least two different key pairs for each subscriber:

  • One key pair is used exclusively for the bank-technical electronic signature.
  • The use of one single key pair is allowed for identification and authentication of the subscriber by the bank system AND decryption of transaction keys.

This decorrelates the authentication and signature certificates, and allows to achieve the following goals:

  • The authentication identifies the entity acting as the unique sender of the request. This entity might be a physical person as well as an abstract entity (a company or a business entity for example), it doesn't matter.
  • In the case of a request sent toward the bank, the request must be signed by one or several physical persons (depending on several criterion) to be taken into account by the bank. It is possible that none of these persons act as the sender.
  • The authentication certificate may be stored on a disk, along with software configuration files or its database. This allows automatic processing like fetching accounts balance, last transactions status, etc. (these requests still require authentication, thus authentication certificate usage)
  • The signature certificate however, identifying the physical person, must be stored in a physical token (cryptographic USB key or smartcard) remaining in possession of this person and requiring a PIN code to be used.
WhiteWinterWolf
  • 19,082
  • 4
  • 58
  • 104
0

I'd say most of your arguments are valid. Typically certs used for signing have different key usage, for example "non repudiation". Many legal requirements (in various countries for example in EU) exists for digital signatures, if they shall be valid in court etc. These requirements do no exist on authentication certificates. All what you state as 1,2,3,4,5,6 I'd say are valid points.

Naturally it always depends on the specific use case, and in an enterprise environment it may be totally moot, while it's a hard requirement in a government environment.

primetomas
  • 111
  • 5