El jueves, 2 de julio de 2020, 9:23:19 (UTC+2), Paul van Brouwershaven escribió: > But as Pedro also mentioned, the EKU extension in intermediate certificates > acts as a constraint on the permitted EKU OIDs in end-entity certificates, > which means you won't be able to use delegated OCSP signing certificates > with strict EKU validation on the path? While not every client might have > strict validation on this, it would be really confusing if it's required > for one EKU and forbidden for the other. >
If we look at the BR, it says: "[^**]: Generally Extended Key Usage will only appear within end entity certificates (as highlighted in RFC 5280 (4.2.1.12)), however, Subordinate CAs MAY include the extension to further protect relying parties until the use of the extension is consistent between Application Software Suppliers whose software is used by a substantial portion of Relying Parties worldwide." Therefore, in my humble opinion it's fully logical to understand this requirement "as it's written", which is to restrict the CA and protect relying parties... In other words, the BR is clearly saying that the meaning of the EKU in SubCAs MUST be understood as a constraint and NOT to express the EKU of the certificate itself. The same applies to other EKUs, for example the meaning of serverAuth EKU is EVIDENTLY associated to a constraint, and no one understands that the CA certificate can be used to protect a web server, as in that case the rest of the certificate profile should be also consistent with the requirements of the leaf TLS certs... I think it's not logical to consider in the BR the implications of setting some EKU and not the others. I would consider this as two derived issues that need to be considered separately and appropriately: #1. There's an evident "gap" in the BR in section 7.1.2.2-g that is creating a potential inconsistency with the RFC, and also creates incompatibilities with certain software solutions. #2. This inconsistency could provoke in certain conditions a security risk, and in particular this applies in case of externally-operated subCAs. This security risk must analysed and mitigated by, maybe, revoking these SubCAs. But I would say that just considering this as a unique problem that needs a unique solution is not appropriate. Best, Pedro _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
