0

I've observed the practice of generating dedicated issuer CAs for signing TSU (Time-Stamping Unit) certificates instead of just using another existing issuer CA, for example, one used to sign S/MIME certificates or SSL certificates.

Now, some examples of the certification paths I found around:

- CN=DigiCert Assured ID Root CA,OU=www.digicert.com,O=DigiCert Inc,C=US
  - CN=DigiCert SHA2 Assured ID Timestamping CA,OU=www.digicert.com,O=DigiCert Inc,C=US
    - CN=TIMESTAMP-SHA256-2019-10-15,O=DigiCert\, Inc.,C=US

- CN=Chambers of Commerce Root,OU=http://www.chambersign.org,O=AC Camerfirma SA CIF A82743287,C=EU
  - CN=AC Camerfirma TSA CA,O=AC Camerfirma SA,serialNumber=A82743287,L=Madrid (see current address at www.camerfirma.com/address),[email protected],C=ES
    - CN=Certificado TSU GSD,O=GSD SAC,L=Lima,[email protected],C=PE

- CN=Global Chambersign Root - 2008,O=AC Camerfirma S.A.,serialNumber=A82743287,L=Madrid (see current address at www.camerfirma.com/address),C=EU
  - CN=AC Camerfirma Portugal - 2015,L=Madrid (see current address at www.camerfirma.com/address),serialNumber=A82743287,O=AC Camerfirma S.A.,C=ES
    - CN=DigitalSign Primary CA,L=Guimaraes (see current address at www.digitalsign.pt),serialNumber=PT507015851,O=DigitalSign Certificadora Digital,C=PT
      - CN=DigitalSign TSA CA,O=DigitalSign Certificadora Digital,L=Guimaraes (see current address at www.digitalsign.pt),C=PT,serialNumber=PT507015851
        - CN=SigningHub Timestamping Service,OU=SigningHub Cloud Service,O=Ascertia Ltd,C=GB

Where you can find in all of these cases that the name of the issuing CA suggests that it is dedicated for signing TSU certificates.

Now, I see a valid point for this practice in https://security.stackexchange.com/a/109134/10247, where it says:

Using different intermediate CAs will allow you to differentiate end-entity certificates by their issuer. This makes it possible to create trust rules that will limit certificate usage based on their issuer.

But I haven't seen until now the need for any relying party to configure a CA to be trusted only to issue TSU certificates (instead of just relying on their generally trusted CAs to correctly identify TSU certificates with the EKU). Anyway, maybe this practice is more common than what my experience dictates and in that case, have you experienced the need for this before?.

Now, in addition to the previous, do you know of any other reason that could justify generating a dedicated issuer CA just for signing TSU certificates?.

Improve this question
5
  • "But it doesn't look like enough justification to me in this case." - please actually explain why this is not enough justification for you instead of only stating it. For example the "DigiCert SHA2 Assured ID Timestamping CA" intermediate has a clearly restricted extended key usage of only Time Stamping which matches the explanation.
    – Steffen Ullrich
    Jan 16, 2020 at 5:27
  • It depends. Every design (shared TSA or dedicated TSA) is acceptable. It depends mostly on resources you can allocate to TSA. Every new server adds complexity, maintenance costs, possible, licenses. Design decision depends on many factors.
    – Crypt32
    Jan 16, 2020 at 8:36
  • @SteffenUllrich, I've edited the question to indicate that in my (limited) experience it doesn't look like enough justification.
    – Jaime Hablutzel
    Jan 16, 2020 at 14:24
  • @Crypt32, could you share one specific scenario that maybe makes it mandatory to design with a dedicated issuing CA for TSU certificates?. In addition, I see that you refer to this issuing CA as TSA and I've observed in the past that this a common way to refer to the CA in this context, but, is it formally documented anywhere the usage of the "TSA" term to refer to the issuer of TSU certificates?.
    – Jaime Hablutzel
    Jan 16, 2020 at 14:44
  • TSA is a signing certificate used to sign TSP responses. It is not technically correct to use TSA term against CAs, I used it to generalize the term since we are talking about CAs.
    – Crypt32
    Jan 16, 2020 at 15:10

1 Answer 1

Reset to default
2

The question is too broad and/or can be opinion-based. There are no best design approaches to answer all scenarios and PKI design depends on multiple factors. Factors include (but not limited to):

  • business requirements
  • technical resources
  • licenses
  • management structure
  • certificate policies

By deploying separate CA to issue TSA certificates (that are used to timestamp and sign data) you can assign a dedicated management team, protect this CA from possible misuse in the case if there are general-purpose CAs. You can apply different issuance policies (governed by certificate practices) to individual CAs.

PKI is primary business for commercial CA (such as DigiCert, Comodo) and they have enough resources to manage multiple CA groups per purpose: SSL/TLS, code signing, TSA, etc. And most likely every CA group is managed by a dedicated team, so dedicated CAs are necessary in this case.

If you have small certificate volume and all certificates are issued under similar policies, CAs are managed by same team, a dedicated CA may be an overkill.

Every extra CA increases the complexity of the PKI and increase TCO (especially, if HSMs are in use). Thus, the design of PKI tree and how you structure CAs is evaluated in every individual case.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .