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

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

    7 hours 7 minutes ago
  • 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

    6 hours 31 minutes ago