Support custom x509v3 extension key/value pairs of ASN1.OID format

[gallak87]

Is your feature request related to a problem? Please describe.
I am running a hyper ledger fabric blockchain network and identities are managed with x509 certificates. A required custom x509v3 extension uses a key of 1.2.3.4.5.6.7.8.1, with some json blob as a value. I cannot figure out how to get vault CLI to set this custom extension attribute. I tried using allowed_other_sans feature, and set other_sans in my issue call to the key/value with json blob but the resulting output was incorrect. I suppose it doesn't qualify as a "san" but a custom extension attribute.

Describe the solution you'd like
I would like vault to support setting custom x509v3 extension attributes such that my output certificate looks like the following (omitted irrelevant cert info):

Certificate:
  ...
    Subject Public Key Info:
     ...
        ASN1 OID: prime256v1
        NIST CURVE: P-256
    X509v3 extensions:
    ...
      X509v3 Subject Alternative Name: 
        DNS:1b80cd8b1cbe
      1.2.3.4.5.6.7.8.1: 
        {"attrs":{"company.ADDR":"XZPYGWWht3fRa2rgMVA3dxpfCW4dcUDXUdsaUFwh17FLvJUDm","company.Affiliation":"Company1","hf.Affiliation":"company1","hf.EnrollmentID":"company1.domain.com","hf.Type":"orderer"}}
  Signature Algorithm: ecdsa-with-SHA256
...

Specifically the last bit here with the key/value pair:

      1.2.3.4.5.6.7.8.1: 
        {"attrs":{"company.ADDR":"XZPYGWWht3fRa2rgMVA3dxpfCW4dcUDXUdsaUFwh17FLvJUDm","company.Affiliation":"Company1","hf.Affiliation":"company1","hf.EnrollmentID":"company1.domain.com","hf.Type":"orderer"}}

This is a custom x509v3 extension attribute that I suppose is unnamed with a key of 1.2.3.4.5.6.7.8.1

Describe alternatives you've considered
One alternative is to use openssl for the whole process, or maybe to just generate the CSR and use the flag use_csr_values but I have not tried this approach yet. However I want vault handle all the steps in the process and to be the CA for my hyper ledger fabric identity management.

Explain any additional use-cases
n/a

Additional context
For reference, HLF ships with a default fabric-ca client/server that automatically handles these kinds of attributes. A reference guide is here: https://github.com/hyperledger/fabric-chaincode-go/blob/master/pkg/cid/README.md#attribute-format-in-a-certificate

[gokuatkai]

We would like to use cert auth for our puppet agent, and we would like to make the policy dynamic according to predefined OID from the agent cert.
The policy 'Templating Parameters' does not support access to OIDs, it would great if they could be added as metadata.
Would that be possible?

[Malshtur]

We would also like to be able to use this feature. At the moment, we use vault and another solution supporting custom metadata. This other solution provides certificates with metadata upon which are vault policies are based with acme dns challenge. Then vault agent with this certificate is able to interact with vault server. It works but we would prefer a full vault solution.

[celesteking]

allowed_other_sans doesn't enforce/set values when the cert request doesn't contain any other_sans param. It just silently issues the cert. How come this slipped through tests?