giovedì 1 marzo 2012 13:49
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 126.96.36.199.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 188.8.131.52.4.1.xxxxx.509.1.2, 184.108.40.206.4.1.xxxxx.509.1.3 & 220.127.116.11.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 18.104.22.168.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 22.214.171.124.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.
Tutte le risposte
martedì 6 marzo 2012 15:53I think that's correct. It's better to state the OID.
martedì 6 marzo 2012 17:00
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.
martedì 6 marzo 2012 19:24Hi 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:
My take on this is only from practical experience - I'm not sure it is actual "expected" behaviour.
Kind regards, Dave
mercoledì 7 marzo 2012 17:35
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.
mercoledì 7 marzo 2012 17:59
venerdì 9 marzo 2012 16:58
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
Notice = “Some text saying CA issues certs in accordance with CP defined by top level OID”
URL = “http://address”
Thanks again for your input.
- Contrassegnato come risposta Douks venerdì 9 marzo 2012 17:00