4

A bit of background. Our organization is working on a document format that will be ingested by our software. We're using the CMS format to verify the integrity (by validating the signature). The CMS message format will contain the chain of the signer, and thus we will also use that to verify trust against the default system keychain (Java's cacerts in our case).

For our first release we'd like to verify that our organization is the one who has signed the document. Our team has looked into certificate pinning. In this case we would include a copy of the x509 certificate that we expect to be the singer and confirm (after we've done the signature validation and trust evaluation) that the signer equals the expected. We decided against it for a couple reasons. The biggest reason is that if a key was compromised or a cert expired we'd have to re-ship our software or make our users make a configuration change (switch the old cert for a new). We'd rather let a public CAs CRL take care of revocation for us.

One idea that we're leaning towards is to verify that the "organization" of the (verified) signers x509 subject is our organization. This seemed like a good compromise between certificate pinning and trusting anyone with a pre-trusted certificate.

In general, is it valid to trust the information that's provided in a certificate's subject if we trust the issuer of the certificate? I.E. Can I be positive that every Certificate Authority included within a non-compromised default trust store (again, Java's cacerts for us) will have verified the the organization that's listed in the subject is the actual organization? Does that extend to other subject fields such as state, local, email, etc? Outside of certificate pinning, is there a paradigm I'm missing that's meant to accomplish this sort of thing?

Improve this question
3
  • Re-reading your question, I suspect that my answer is jumping at shadows. If so, please add information to the question to address the concerns I raise, and I'll update my answer.
    – Mike Ounsworth
    Commented Apr 26, 2016 at 22:49
  • No worries. Updated the question. Hopefully that clears up your questions.
    – Staros
    Commented Apr 26, 2016 at 23:17
  • Thank you for the edits. This is a much more interesting question than it seemed the first time. I'll overhaul my answer in a few minutes.
    – Mike Ounsworth
    Commented Apr 26, 2016 at 23:26

2 Answers 2

Reset to default
2

Addressing your points:

Our team has looked into certificate pinning [of the document signing cert]. ... We decided against it for a couple reasons. The biggest reason is that if a key was compromised or a cert expired we'd have to re-ship our software ... We'd rather let a public CAs CRL take care of revocation for us.

Yup, that makes sense. Public Key Infrastructure (ie CA hierarchies) exists to solve problems exactly like this, so take advantage of it!

Can I be positive that every Certificate Authority included within a non-compromised default trust store (again, Java's cacerts for us) will have verified the the organization that's listed in the subject is the actual organization?

Yes, that is kinda the whole reason CAs exist, and that they are publicly trusted. That said, I think you're really trying to ask something different. This does not guarantee uniqueness; ie that there are no other valid certs out there with an Organization field that match yours. For example, consider that your company, "Flower Power, inc", is incorporated in the US. I could incorporate a brand new company under the name "Flower Power, inc" in Germany, and there's no reason that a CA should deny me a cert with ou=Flower Power, inc. I would recommend using something even more unique, like the domain name of your website, or the full DN of your organization, including country code, which I think you're getting at with your next sentence.

You might be interested in Google's new technology called Certificate Transparency. The idea of CT is that all of the publicly trusted CAs need to publish a copy of every certificate they issue to a public log server. Your company could set up a background task - say once an hour - to check the CT logs for other certs containing the same Organization identifier as you. This wouldn't prevent the CA from issuing it, but at least you'd be notified if there ever was a conflict.

Does that extend to other subject fields such as state, local, email, etc?

Yes, it should.

To be extra sure that the CA is doing their job well, you could get yourself an Extended Validation certificate and require that your client is presented with an EV cert by making sure that it contains one of the EV Policy OIDs mentioned in this table.

Outside of certificate pinning, is there a paradigm I'm missing that's meant to accomplish this sort of thing?

Umm, if you want all of this rooted to the publicly trusted CAs, then what you're doing - while complicated - might be the best bet.

I'm not at all familiar with the CMS format, but the way I would architect this would be to host your own root CA and intermediate CA in-house and only ever use that CA to issue document signing certificates for your format. That way you actually can trust any cert issued off that root. Extending that to allow other organizations to sign your format would kinda require you to become a public CA - but the effort might be worth it if you want to stay in control of your format.

Improve this answer
2

[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

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.
  2. 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.
  3. 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.
  4. 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).

Improve this answer
0

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .