On Sat, Jan 28, 2023 at 11:57:46AM +0200, Oleg Pekar wrote: > Dear TLS WG, > When TLS party receives other party's certificate chain, there is a rule > for validation of end-entity certificate EKU specified by the RFC 3280, > section "4.2.1.13 Extended Key Usage": > > "If the extension is present, then the certificate MUST only be used > for one of the purposes indicated. If multiple purposes are > indicated the application need not recognize all purposes indicated, > as long as the intended purpose is present. Certificate using > applications MAY require that a particular purpose be indicated in > order for the certificate to be acceptable to that application. > > If a CA includes extended key usages to satisfy such applications, > but does not wish to restrict usages of the key, the CA can include > the special keyPurposeID anyExtendedKeyUsage. If the > anyExtendedKeyUsage keyPurposeID is present, the extension SHOULD NOT > be critical." > > However the RFC doesn't require CA certificates in the party's chain to > follow the same rule as the end-entity certificate.
Right. By RFCs, the EKU of CA certificates does not matter. > Example: if the client sends a chain Root->CA1->CA2->End-Entity, then the > End-Entity certificate, if EKU is present in it, must include > EKU=clientAuth. But Root, CA1, CA2 can have EKU=serverAuth (and don't > include EKU=clientAuth at all). Such a chain would be considered valid from > the RFC perspective, nevertheless it is counter-intuitive. Due to this > potential gap some implementations (including OpenSSL) apply the same > validation rules for client end-entity certificate to client's chain CA > certificates and this creates incompatibility between implementations. > > * Am I missing a standard that explicitly regulates EKU for CA certificates > in the party's chain? The standard interpretation in WebPKI is that EKU of CA certificates does matter, and I guess this has spilled over to a number of non-Web TLS implementations. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
