none
2 Tier PKI and multiple OIDs

    שאלה

  • 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

    יום חמישי 17 מאי 2018 13:22

כל התגובות

  • 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.

    יום חמישי 17 מאי 2018 13:39
  • 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

    יום חמישי 17 מאי 2018 13:50
  • 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

    יום חמישי 17 מאי 2018 19:03
  • 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

    יום חמישי 17 מאי 2018 19:22
  • 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



    • נערך על-ידי Cristian Ruiz יום חמישי 17 מאי 2018 23:39
    יום חמישי 17 מאי 2018 23:39
  • > 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.

    יום שישי 18 מאי 2018 09:09
  • 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

    יום שלישי 22 מאי 2018 18:35
  • 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

    יום שלישי 22 מאי 2018 19:12