Paul Hoffman wrote, On 2008-03-04 07:49: > Here is a slightly edited version of what a lead security developer > at Microsoft told me with regard to EKUs and path processing. [snip]
> Every root certificate is stored with some properties that are not > cryptographically bound to the certificate, but are protected by > other mechanisms that protect the integrity of the root store. A root > may have EKU assigned to it either through an EKU extension, or by > properties in the root store. [snip] > A certificate is considered consistent with the root EKU if each CA > certificate in the path either has an absent EKU extension or express > an EKU consistent with the intended usage. [snip] > The EKUs valid for a [root] certificate [are] the intersection of EKUs > in the root and EKUs set as root parameters. Empty parameters or absent > EKU extension counts as Any. [snip] > The normal case is that the root certificate does not have any EKU > extension and that all EKUs are expressed as parameters set by > Microsoft. [snip] > Microsoft chain validation honors extensions in roots [and] process > them if they have any relevance for path processing. [snip] It is > specifically allowed in RFC 3280 section 6 to further constrain path > validation from the standard algorithm. > [snip] The important thing here is that we do not require EKUs in > roots, but if they are present, we do honor them and do not validate > end certificates with conflicting EKU under such root. This matches the understanding that we received from Microsoft representatives at a CAB Forum meeting in the summer of 2006. It is good that they have now published that behavior. I believe it applies to KUs and EKUs and indeed ANY cert behavior-limiting extensions that may be found in certs, including Basic Constraints and Name Constraints. The last paragraph quoted above matches the long-time behavior of NSS with respect to EKUs in root certs. At the risk of praising the competition (:-), as I view it, MS Windows' ability to add KUs, EKUs and other cert behavior-limiting extensions to root certs is similar to NSS's ability to set trust flags on root certs for specific capabilities (such as SSL, S/MIME, code signing) that happen to map to KUs, EKUs, and Basic Constraints, and is more flexible, in that it can be applied to ANY cert behavior-limiting extensions, while NSS's trust flags presently only apply to specific pre-defined sets of capabilities that map to KUs, EKUs and Basic Constraints. I hope that the NSS team will someday have the resources to add a similarly flexible capability to NSS. /Nelson _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
