_[Note: In the first wording of the question, there appeared to be some pretty glaring conceptual problems, the re-wording fixed these. I am going to leave this answer here anyway in hopes that it's useful to somebody.]_

## PKI Fundamentals

I think we need to go back to basics on how Public Key Infrastructure and certificates work. I am going to shamelessly steal a photo of a certificate chain:

[![cert chain][1]][1]

In this scenario, User1 would be your document signer, which sign documents using a certificate issued by some Certificate Authority (CA), which could be a self-signed root CA or could be an intermediate CA with a root above it.

### Validating a certificate chain

Let's say that I as the client want to validate the signature on a document that User1 signed. The procedure would be this:

1. **Validate the signature on the document**: hash the document yourself, and then use the public key in User1's cert to check that your hash matches the one in the `signature` field.
1. **Validate User1's cert**: Ok, I know that the document was signed by the key identified in User1's cert. How do I know that this key _actually_ belongs to User1 and that this isn't a fake cert? Well, this cert is signed by an IssuingCA, so I will validate the signature on User1's cert against the key in the cert for the IssuingCA.
1. **Validate the IssuingCA's cert**: Ok, I know that User1's cert was signed by the key identified in the IssuingCA's cert. How do I know that this key _actually_ belongs to the IssuingCA and that this isn't a fake cert? Well, this cert is signed by the RootCA, so I will validate the signature on the IssuingCA's cert against the key in the cert for the RootCA.
1. **Validate the RootCA's cert**: Well, since it's this cert is self-signed, there's no way to validate it, so I will check that it matches bit-for-bit (or that its hash matches) one of the certs that I've pinned (aka is in my trust store).

## Your Situation

You say:

> Our team has looked into certificate pinning but decided against it for a couple reasons. ... We'd rather just validate against the system trust and let a public CAs CRL take care of revocation for us.

Then how, pray tell, are you doing that validation if you haven't pinned the root cert?? How are you validating the signature on the CRL to make sure that it hasn't been faked? What happens if I whip up my own `OpenSSL` CA on my linux box and issue myself a cert with the identical `subject` as your cert (ie is bit-for-bit identical to your signing cert except for the public key and signature)? Please tell me that your software would reject it.


----------

## Answering your questions

> In general, is it valid to trust the information that's provided in a certificate's subject?

Uhh, no. Not unless you've validated the signatures on the certificate all the way back to a root cert that you have pinned.

> Is there a way for me to obtain an x509 certificate from a pre-trusted authority that contains information in the subject that has not been validated?

I'm not sure I understand the question. Validated by who? A public Certificate Authority (CA) should verify all information in the `Subject` and `SubjectAltName` fields before issuing the cert. If not, then that CA deserves to go out of business. Your client software should also validate the contents of a certificate every time it sees one by tracing the signatures back to a pinned root.

> Do we have to verify that the certificate has the "Code Signing Certificate" extend key usage to get that guarantee?

Umm, that depends, is it signing code? ie are the "documents" in question executable software (`.exe` files, or installers)? If not then you should be checking for the "Digital Signature" extension. (The point of this extension is to make sure that a certificate / key gets used for one thing and one thing only. If a key gets "re-purposed" halfway through its life, this can lead to vulnerabilities).

  [1]: https://i.sstatic.net/lSFTR.gif