Feature Request: Access to additional properties of peer certificates

[DerekTBrown]

Usecase

• I am attempting to write a WASM Proxy plugin that accesses x509 extensions of the client certificate.
• Currently, only a limited set of certificate properties are supported. This does not include x509 extensions:

  • spec/abi-versions/v0.2.1/README.md

    Lines 1769 to 1781 in 155da15

    	* `connection.subject_local_certificate` (string) - subject of
    	the local certificate
    	* `connection.subject_peer_certificate` (string) - subject of
    	the peer certificate
    	* `connection.dns_san_local_certificate` (string) - first DNS entry in
    	the local certificate
    	* `connection.dns_san_peer_certificate` (string) - first DNS entry in
    	the the peer certificate
    	* `connection.uri_san_local_certificate` (string) - first URI entry in
    	the local certificate
    	* `connection.uri_san_peer_certificate` (string) - first URI entry in
    	the peer certificate
    	* `connection.sha256_peer_certificate_digest` (string) - SHA256 digest of

Proposal

I could forsee two paths to implement this behavior. I wanted the community's input on which approach to take:

Option A: Expose x509 Extensions via Property

A narrow solution to this problem would propose the inclusion of x509 extension values via the properties API:

 auto buf = getProperty({"connection", "x509_extensions_peer_certificate"});
 if (buf.has_value()) {
      for (const auto& [key, val] : buf.value()->pairs()) {
          LOG_INFO("Got extension": key+" - "+value);
      }
  }

Pros:

• Higher performance than Option B.

Cons

• Implementing passthrough functionality to each attribute of a certificate is likely not maintainable in the long-term. I could easily imagine many other similar requests in the future for different attributes of the certificate.

Option B: Expose DER-encoded certificate via properties

A broader solution to this problem would provide a direct DER interface to the underlying certificate via the getProperty interface:

 auto buf = getProperty({"connection", "der_peer_certificate"});
 if (buf.has_value()) {
      // Parse the DER-encoded certificate on the plugin side.
  }

Pros

• This is much more maintainable than Option A, since users can parse whatever properties they need out of the certificate.

Cons

• This is less performant than Option A:
  • We have to pay a CPU cost to serialize the string into DER format.
  • We have to copy the entire DER as a string, which is expensive.
  • We have to pay additional DER cost to deserialize the DER format on the WASM plugin side, when the host has presumably already deserialized the certificate.

Closing Notes

• Thanks in advance for all your feedback!
• I am new to the proxy-wasm project, so let me know if there are other options that should be considered.

[kyessenov]

I think it option B would probably work for more hosts, but on Envoy, you might already have it parsed, and option A would be more efficient. Is this for OIDs? It probably depends if it's a standard extension or not.

[DerekTBrown]

Is this for OIDs?

My main use case is to parse OIDs.

[DerekTBrown]

It probably depends if it's a standard extension or not.

My usecase is for a non-standard extension, so parsing specific fields as high-level properties isn't going to help.

[DerekTBrown]

I wrote a prototype of this for Envoy via method A:

envoyproxy/envoy#40178