Here is a slightly edited version of what a lead security developer at Microsoft told me with regard to EKUs and path processing.
To the core issue. Does EKU need to be in the root certificate. The answer is: no. 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. The properties in the root store are added by Microsoft upon acceptance of the root for one or more purposes. These EKU properties are used to ensure that e.g. only roots approved for code signing can be used to validate code integrity of software components. For this to work, Microsoft path validation also checks that the end certificate is consistent with the EKU property of the root. This part adds to X.509 and rfc 3280bis. 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. The end certificate is treated with respect to EKU exactly according to the standard. When our path validation algorithm checks for EKU consistency we first determine what EKU's that are valid for a root certificate. The EKU's valid for a certificates is the intersection of EKU's in the root and EKU's set as root parameters. Empty parameters or absent EKU extension counts as Any. So: If a Root contains EKU A, and parameters express EKU B, then this root is not valid for any EKU at all. If the Root express EKU A and B and Parameters express EKU B, the root is valid for EKU B only. If the Root express EKU B and no parameters are set, the root is valid for EKU B still The normal case is that the root certificate does not have any EKU extension and that all EKU's are expressed as parameters set by Microsoft. Microsoft chain validation honor extensions in roots an process them if they have any relevance for path processing. Technically you can see this as an extended validation process where we expand the inputs to the path validation algorithm. This results in path validation that is further constrained from what is specified in rfc3280. It is specifically allowed in rfc3280 section 6 to further constrain path validation from the standard algorithm. As I said before, Microsoft EKU processing is expanding on the standard in a way that does not break the standard, but do indeed further constrain it. The important thing here is that we do not require EKU's in roots, but if they are present, we do honor them and do not validate end certificates with conflicting EKU under such root. _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
