1

In RFC-4519 stateOrProvinceName is abbreviated to ST. Should we assume that it is best practice to put ST=<name-of-state> in the certificate if the state or province is indicated? After all X-500 also has the acronyms S and SP reserved for state or province.

Which acronyms should we allow when it comes to accepting certificates? Should we make sure that the acronyms match, or should we only compare the actual values? Should we reject the certificate in the strange case that we have multiple values?

I guess that OID's have also been specified, would it be an idea to use those instead of the acronyms. Could we use the full stateOrProvinceName as well?

Finally, I would like to know how OpenSSL handles this during creation and validation, as it is probably the most used application to create leaf certificates and probably the most common server side TLS implementation as well.

1 Answer 1

1

Which acronyms should we allow when it comes to accepting certificates?

neither. See below.

I guess that OID's have also been specified, would it be an idea to use those instead of the acronyms.

in fact, acronyms are platform/tool specific and potentially can be localized. For example, Windows uses S or ST acronym for this attribute and do not recognize SP.

In certificates, all RDN attributes are identified by OID, which is platform-agnostic. If you want to read/validate the ST attribute you should lookup by using OID (2.5.4.8).

Should we reject the certificate in the strange case that we have multiple values?

I would say "no" unless there is a specific requirement for this. Geo attributes (like Locality, StateOrPrivince, Country) are mostly informational and are not used as certificate acceptance criteria.

4
  • " are mostly informational and are not used as certificate acceptance criteria" they are in the standard I'm reading, which is also why I'm asking for acceptance criteria, which of course are not completely specified in it. I'll check what my Java can do with the OID while the certificate uses an acronym... Jun 8 at 12:01
  • they are in the standard -- they are defined in the standard. The RFC doesn't imply how this attribute should be processed. Processing rule definitions are left to application/protocol implementers. And I'm not aware about any standard that use ST as acceptance criteria. Everywhere it is either informational or just part of X.500 directory path.
    – Crypt32
    Jun 8 at 14:00
  • It is in IEC 18013-5 / mDL: "stateOrProvinceName is optional. If this element is present, the element shall also be present in the end-entity certificates and hold the same value. The value shall exactly match the value of the data element “issuing_jurisdiction”, if that element is present on the mDL." . So this is opening this specific can of worms. Fortunately it does mention RFC 4519, so we can asume that you have to use ST (case insensitive). Jun 8 at 14:25
  • Furthermore: "If device retrieval is used, if the mDL reader retrieved the “issuing_jurisdiction” data element, it shall verify that the value of that element matches the stateOrProvinceName element in the subject field within the DS certificate (see Annex B). This is only required if the stateOrProvinceName element is present in the DS certificate.". However, in that instance it is stored in a CBOR field called stateOrProvinceName . This is for the signed data rather than a certificate. Note that e.g. in the US the driver licenses are issued for each state separately. Jun 8 at 14:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.