none
More PolicyStatementExtension OID Limitations

    Domanda

  • Hi

    Following on from http://social.technet.microsoft.com/Forums/en-US/winserversecurity/thread/021bc361-6186-47fa-aff5-7707cb3bad6e I have found with testing that there are more limitations than we thought when it comes to certificate templates.

    Lets say you specify a single OID in PolicyStatementExtension of a CA, eg 1.3.6.1.4.1.xxxxx.509.1, which represents your organisations Certificate Policy (CP). Lets also say that within this CP you are going to define 3 levels of assurance: Basic, Medium & High with OIDs of 1.3.6.1.4.1.xxxxx.509.1.2, 1.3.6.1.4.1.xxxxx.509.1.3 & 1.3.6.1.4.1.xxxxx.509.1.4 respectiveley.

    You want your issued certificates to idicate the level of assurance with which they were issued. Taking Basic as an example, you modify your certificate template Extensions to include an Issuance Policy, select new & then define name of Basic Assurance and OID of 1.3.6.1.4.1.xxxxx.509.1.2.

    You then request a certificate based on this template, but the request fails due to Invalid Issuance Policies. (which goes against what was said in the previous thread)

    If, instead of Basic Assurance, you modify the certifiate template Extensions to include 1.3.6.1.4.1.xxxxx.509.1, a subsequent request will succeed, but clearly the issued certificate won't indicate the assurance level, just the top level CP.

    If you don't assign any Issuance policy to the certifiate template Extensions, then the request will succeed but the resulting certificate won't have any issuance policies included. 

    So, I think that if you need to indicate assurance level in an issued certificate, then you had better include that OID (could be several) in the PolicyStatementExtension of the CA in the first place.

    Please could the community confirm that this behaviour / understanding is correct, and if it's new to 2008 R2.

    Thanks


    Douks



    • Modificato Douks sabato 3 marzo 2012 20:31 clarification
    giovedì 1 marzo 2012 13:49

Risposte

  • Thanks Kevin & Dave for your input - really helpful.

    I have reviewed RFC5280 and RFC3647. In RFC3647 section 3.3.1 states:

    "When processing a certification path, a CP that is acceptable to the
       relying party application must be present in every certificate in the
       path, i.e., in CA-certificates as well as end entity certificates."

    So, the behaviour we've seen is technically correct - Defining sub OID's in certificate templates would NOT meet the stated requirement, so it is GOOD that 2008 / R2 doesn't permit it.

    So you MUST include all required OID's in the capolicy.inf of the CA in the first place.

    I guess you could still include your base OID for CP if you wanted the certificate Issuer Statement button to still work  and be useful when the CA cert is viewed. This would keep the OID arc principle alive, and allow your CP to define 3 levels of assurance.

    example might be

    [PolicyStatementExtension]
    Policies=CP,BasicAssurance,MediumAssurance,HighAssurance
    Critical=0
    [CP]
    OID=1.3.6.1.4.1.xxxxx.509.1
    Notice = “Some text saying CA issues certs in accordance with CP defined by top level OID”
    URL = “http://address”
    [BasicAssurance]
    OID=1.3.6.1.4.1.xxxxx.509.1.2
    [MediumAssurance]
    OID=1.3.6.1.4.1.xxxxx.509.1.3
    [HighAssurance]
    OID=1.3.6.1.4.1.xxxxx.509.1.4

    Thanks again for your input.


    Douks

    • Contrassegnato come risposta Douks venerdì 9 marzo 2012 17:00
    venerdì 9 marzo 2012 16:58

Tutte le risposte

  • I think that's correct. It's better to state the OID.
    martedì 6 marzo 2012 15:53
  • Thanks for the contribution.

    My reason for posting this question is that I've not found this information explained in detail anywhere on the web, or in any publication...

    Have you observed this behaviour, or used this technique to deploy multiple issuance policies in a live environment?

    I'm keen to understand if this is new to R2 since most advice on the web etc suggests just including the CPS OID, which won't result in a configuration (certainly with R2 anyway) that permits different levels of issuance policy to be defined in end entity certs.

    Can anyone else add anything?

    It seems this aspect of MS PKI is challenging & maybe most people don't encounter since CP / CPS might be considered not necessary for a typical internal enterprise type deployment.

    If I can get a couple more opinions & a concensus, I'll write it up for a wiki article to hopefully help others in the future.

    Thanks


    Douks

    martedì 6 marzo 2012 17:00
  • Hi Douks,
    My understanding is that you should only need to define the "parent OID arc" in your CA certificate and then specify "child OIDs" in the certificate templates.  However, my practical experience has been very similar to yours and although I'm generally working with third-pary RAs that don't encounter the enrolment problems you are having - I have often seen problems in chain verification if the certificate policy OID in the end certificate doesn't reflect a certificate policy explicitly stated in the issuing CA certificate.

    So, if faced with your scenario I'd include in the policy statement extensions of the CA certificate:
    • 1.3.6.1.4.1.xxxxx.509.1.2
    • 1.3.6.1.4.1.xxxxx.509.1.3
    • 1.3.6.1.4.1.xxxxx.509.1.4
    I wouldn't ordinarily include the parent OID arc (1.3.6.1.4.1.xxxxx.509.1 in your case).

    My take on this is only from practical experience - I'm not sure it is actual "expected" behaviour.

    Kind regards, Dave
    martedì 6 marzo 2012 19:24
  • Thanks Dave - useful to note your experiences...

    I agree to get the different assurance levels in the end certificates it seems it is necessary to include the individual OID's in the policy statement extensions of the CA.

    Still not clear if this is new to 2008 / 2008 R2 - hope someone can confirm.

    It seems to me that this functionality (if new & by design) could be seen as a step backwards. Including a single "CP/CPS" OID in a CA's policy statement extensions, as is generally accepted as best practice, could actually lead to problems later on.

    That said, most high assurance deployments I've seen (non-microsoft by the way) do exactly what seems to be being imposed on us here, ie include the specific OID's in the CA cert extensions in the first place.

    It's not a problem as such, but it is important that those designing & implementing PKI's are aware of the limitation so they can take it into account.


    Douks



    • Modificato Douks mercoledì 7 marzo 2012 17:36 another typo
    mercoledì 7 marzo 2012 17:35
  • Hi Douks,

    I can confirm that the chain building behaviour problems I described have been independent of whether the relying party was a Windows Server 2003 or Windows Server 2008 / R2 platform.  So, even if you could in Win2K3 Server get an enrolment to work with "unaligned OIDs" I should be careful that you still have a problem when actually using those certificates on various platforms.

    I also agree that it's not a problem as such, just something to be aware of - it'd be helpful if some kind of paper / KB article was published in this area.  I've seen people deploy issuing CAs without fully considering all the CP OIDs they're gonna be asserting from that CA - and getting into problems later on.

    Regards, Dave

    mercoledì 7 marzo 2012 17:59
  • Thanks Kevin & Dave for your input - really helpful.

    I have reviewed RFC5280 and RFC3647. In RFC3647 section 3.3.1 states:

    "When processing a certification path, a CP that is acceptable to the
       relying party application must be present in every certificate in the
       path, i.e., in CA-certificates as well as end entity certificates."

    So, the behaviour we've seen is technically correct - Defining sub OID's in certificate templates would NOT meet the stated requirement, so it is GOOD that 2008 / R2 doesn't permit it.

    So you MUST include all required OID's in the capolicy.inf of the CA in the first place.

    I guess you could still include your base OID for CP if you wanted the certificate Issuer Statement button to still work  and be useful when the CA cert is viewed. This would keep the OID arc principle alive, and allow your CP to define 3 levels of assurance.

    example might be

    [PolicyStatementExtension]
    Policies=CP,BasicAssurance,MediumAssurance,HighAssurance
    Critical=0
    [CP]
    OID=1.3.6.1.4.1.xxxxx.509.1
    Notice = “Some text saying CA issues certs in accordance with CP defined by top level OID”
    URL = “http://address”
    [BasicAssurance]
    OID=1.3.6.1.4.1.xxxxx.509.1.2
    [MediumAssurance]
    OID=1.3.6.1.4.1.xxxxx.509.1.3
    [HighAssurance]
    OID=1.3.6.1.4.1.xxxxx.509.1.4

    Thanks again for your input.


    Douks

    • Contrassegnato come risposta Douks venerdì 9 marzo 2012 17:00
    venerdì 9 marzo 2012 16:58