Question

I have a system in which X509 certificates can have a number of "schemas" where a schema is is a collection of the exact OIDs that are required/optional in the subject of the cert. The application that verifies these certificates needs to know what schema (and what version of that schema) has been used for a given certificate.

For example, Schema A requires CN, O, OU and schema B requires CN, UID, O, C, ST.

I'm looking for a standard way to encode the schema (+ version) in the certificate so the receiving application can tell from the certificate how to parse it. Solutions:

  1. Hijack some totally unrelated OID to stuff this information into the subject. I don't like this, but it would work as a hack-y fallback.
  2. Utilize an extension. I think the Subject Directory Attributes looks like it might be appropriate, but then it still seems to require OID name/value pairs as its payload, so again which OIDs?
  3. Something else entirely?

Again, I can make this work with #1 or could do a similar hack with #2, but what I really want is a standard non-hack way to accomplish this goal.

Was it helpful?

Solution 2

I've ended up utilizing a UUID-based OID under the 2.25 arc for each of my my two metadata fields (schema and version).

The site below offers a UUID generator as a convenience and a registration link (although registration isn't strictly required):

http://www.itu.int/ITU-T/asn1/cgi-bin/uuid_generate

OTHER TIPS

I'd assume you would care about what schema is used. So that means that you probably have exactly those fields in the DN - and that they are also making up the breath of exactly what is signed by the CA (with the mandatory sundry). So assuming your schema's are different - that would let you distinguish them.

Another option would be a (sub)CA per scheme; or simply use the netscape comment field :).

In my experience however - when it is relevant for the organization to thus advertise, recognize/reconstruct and interpret the scheme - that generally means that it has some business purpose. So it generally has a useful business name. In that case; consider an (extra) O or OU (multi variant if needed) with that in there.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top