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. 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. If we take some derived RFCs, e.g. EAP-TLS RFC 5216, it also requests EKU=clientAuth (if present) only from end-entity certificates but not from the client CA chain (Section 5.3. Certificate Validation): "In the case of the server, this involves ensuring the certificate presented by the EAP-TLS peer was intended to be used as a client certificate. Implementations SHOULD use the Extended Key Usage (see [Section]( https://www.rfc-editor.org/rfc/rfc3280#section-4.2.1.13) [4.2.1.13 [RFC3280]]( https://www.rfc-editor.org/rfc/rfc3280#section-4.2.1.13)) extension and ensure that at least one of the following is true: 1) The certificate issuer included no Extended Key Usage identifiers in the certificate. 2) The issuer included the anyExtendedKeyUsage identifier in the certificate (see [Section 4.2.1.13 of [RFC3280]]( https://www.rfc-editor.org/rfc/rfc3280#section-4.2.1.13)). 3) The issuer included the id-kp-clientAuth identifier in the certificate (see [Section 4.2.1.13 of [RFC3280]]( https://www.rfc-editor.org/rfc/rfc3280#section-4.2.1.13))." * Am I missing a standard that explicitly regulates EKU for CA certificates in the party's chain? * If there is really no such standard - should we create one to be more strict on EKU in chain CA certificates to close the potential gap? Thank you, Oleg
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
