Skip to content

Implement EKU chaining for certificate verification #5821

Description

@randombit

RFC 5280's treatment of EKUs is that it applies only to the usage of the public key in the certificate, and thus "In general, this extension will appear only in end entity certificates.". That is how we currently interpret things; EKU of the intermediates are just ignored.

However some implementations appear to add some additional chaining logic on their interpretation, where an intermediate with some EKU (say serverAuth) is restricted from issuing a leaf with a conflicting EKU. And CABF apparently has some rules also relating to this.

It might be worth implementing this kind of check, though it requires some significant research, as it's not clear if there is any consensus on issues like

  • How is anyExtendedKeyUsage treated, either in intermediate or leaf?
  • If an intermediate has an EKU does the leaf have to have an EKU as well?
  • If the path is {root} -> int1 {EKU X, Y} -> int2 {EKU X} -> leaf {EKU X} presumably that's ok. But what about {root} -> int1 {EKU X} -> int2 {EKU X,Y} -> leaf {EKU X} where an intermediate widens the EKU set but the leaf is within the shared EKUs?

Likely this would be an opt-in flag to the validator.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions