On 1/28/23, 8:10 AM, "TLS on behalf of Ilari Liusvaara" <tls-boun...@ietf.org <mailto:tls-boun...@ietf.org> on behalf of ilariliusva...@welho.com <mailto:ilariliusva...@welho.com>> wrote:
On Sat, Jan 28, 2023 at 11:57:46AM +0200, Oleg Pekar wrote: <snip> > 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. [CW] A short RFC that describes WebPKI EKU processing rules along with a new flag for the path validation algorithm that signifies WebPKI EKU processing is in effect may help clarify the situation. Implementations that use WebPKI EKU rules would claim conformance to the new RFC, which would be a superset of 5280. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
