none
2 Tier PKI and multiple OIDs

    Question

  • Hi!

    I must follow a design made by others, where they have defined 4 OIDs, 1 for RootCA, and 1 for each of 3 Issuing CAs (the 3 Issuing CA are intended to be use for different purpose).

    The question is, How is the correct way to define OIDs?.

    Is correct to define 4 OIDs in the RootCA Capolicy file, and then 1 specific OID in each of the Issuing CA?  


    Cristian L Ruiz

    Thursday, May 17, 2018 1:22 PM

Answers

  • When you have certificate policy OIDs defined at an issuing CA, you can:

    - Issue a certificate with no OID in the certificate template (say Web Server as in you rquestion)

    - Issue a certificate with a matching OID (from the available OIDs in the issuing CA certificate) in the certificate template

    You cannot issue a certificate with a unique OID not included in the issuing CA certificate

    Typically, in the CP document, you would state that a certificate without an expressed OID is the equivalent of a low/basic/Class 2 assurance level.

    Brian

    • Marked as answer by Cristian Ruiz Thursday, May 31, 2018 1:08 PM
    Thursday, May 31, 2018 1:01 PM

All replies

  • Why not to ask those who developed this design? We have zero details about your design. There are many kinds of OIDs. Which one you are interested in?


    Vadims Podāns, aka PowerShell CryptoGuy
    My weblog: www.sysadmins.lv
    PowerShell PKI Module: PSPKI
    Check out new: SSL Certificate Verifier
    Check out new: PowerShell File Checksum Integrity Verifier tool.

    Thursday, May 17, 2018 1:39 PM
  • The document was made more than 2 years ago, so is not possible to ask anybody.

    In the design document say that there are 4 CPS, 1 for rootCA certification, 1 for the 1st Issuing CA for Device and Services Certification, 1 for the 2nd Issuing CA for Sign and Authentication Certification, and the last for the 3rd Issuing CA for Encryption. Is enough information? 

    It say that it's going to use a private OID made from forest AD, but you told me in another topic to use a public one from IANA. 


    Cristian L Ruiz

    Thursday, May 17, 2018 1:50 PM
  • I really think that the design is flawed (as you are placing OIDs in the root CA certificate).  Now is the time to review a two year old design and do it right before you deploy.

    Go with a root CA certificate with no OID (yes, you have a CPS for the root, but no need to put an OID)

    For the issuing CAs, put a unique OID for each CP (certificate policy) defined in each CPS. So, if you define low, medium and high assurance in the Devices and Services Certification CA, then you would define the three OIDs in the CAPolicy.inf file. Note that we are defining OIDs for certificate/issuance policies, not CPS docs.

    Finally, yes, use IANA OIDs, not forest OIDs as the forest OIDs are owned by Microsoft

    Brian

    Thursday, May 17, 2018 7:03 PM
  • Ok, so I'm really thinking the design document is flawed, LOL

    Because they defined one CPS for each of the Issuing CA taking in count the porpose of the CA, that is why I was thinking to define one different OID in the Capolicy file of each Issuing CA (with the concept that each OID must map to a specific PDF document, may be I have a wrong concept of OIDs).

    So, having 1 root CA, and 3 Issuing CA (each for different porpuses), what do you suggest? To put 3 OIDs in each of the Capolicy.inf of the 3 Issuing CAs? But in that case each of the OIDs can they have reference for the PDF docs?

    thanks for your help


    Cristian L Ruiz

    Thursday, May 17, 2018 7:22 PM
  • Ok, I was reading Vadims papers, and I understood that the CA Root should not have an OID definition.

    I have 3 Issuing CAs for different purpose, to issue certificates for different use, and every of these CAs will have different templates enabled.

    So, Is correct to define 1 different OID in the Capolicy.inf file of each Issuing CA?

    Thanks in advance 


    Cristian L Ruiz



    Thursday, May 17, 2018 11:39 PM
  • > So, Is correct to define 1 different OID in the Capolicy.inf file of each Issuing CA?

    yes, it is correct. But I may assume that your design may have other design flaws, so I would recommend to review entire design and adjust it according to best practices.


    Vadims Podāns, aka PowerShell CryptoGuy
    My weblog: www.sysadmins.lv
    PowerShell PKI Module: PSPKI
    Check out new: SSL Certificate Verifier
    Check out new: PowerShell File Checksum Integrity Verifier tool.

    Friday, May 18, 2018 9:09 AM
  • Ok, and then the issued certificates for end users and computers should have the same Issuance Policy as configured for the Issuing CA cert?

    Cristian L Ruiz

    Tuesday, May 22, 2018 6:35 PM
  • possibly.

    In some designs, an issuing CA may support multiple issuance policies / assurance levels.

    In this design, the certificate issued to a user/computer would only include a single OID (matching the assurance level of that cert).

    So you would have:

    Root (no OIDs)

    Issuing (BasicAssure, Medium Assure, and High Assure)

    Leaf (Basic Assure)

    The big thing that you cannot do is introduce a *new* OID that does not exist at the issuing CA.

    Brian

    Tuesday, May 22, 2018 7:12 PM
  • Hi! Is it possible to issue certificates, technically speaking, as those issued using the web server template, even if the issuing CA has a defined OID and the certificate does not?

    Cristian L Ruiz

    Thursday, May 31, 2018 12:56 PM
  • When you have certificate policy OIDs defined at an issuing CA, you can:

    - Issue a certificate with no OID in the certificate template (say Web Server as in you rquestion)

    - Issue a certificate with a matching OID (from the available OIDs in the issuing CA certificate) in the certificate template

    You cannot issue a certificate with a unique OID not included in the issuing CA certificate

    Typically, in the CP document, you would state that a certificate without an expressed OID is the equivalent of a low/basic/Class 2 assurance level.

    Brian

    • Marked as answer by Cristian Ruiz Thursday, May 31, 2018 1:08 PM
    Thursday, May 31, 2018 1:01 PM
  • Thanks Brian!

    Cristian L Ruiz

    Thursday, May 31, 2018 1:07 PM