I'm curious about this because the openssl command will create a CSR where stateOrProvince has a two-character (U.S.) state name, and (at least one) CA (Comodo) will happily issue a cert using such a CSR.
Is there any issue with a cert generated using such a CSR? Should the openssl command validate stateOrProvince? If not, then maybe it's just a matter of changing the prompt (I'm happy to submit a PR for such a minor change).
On Aug 30, 2016, at 6:28 PM, Tim Boring <[hidden email]> wrote:
> When creating a CSR, openssl displays the following
> State or Province Name (full name) [Some-State]:
> And a couple lines up from that is a comment pointing to RFC 3280, which defines the following:
The original definition is from X.520, I suppose, which doesn't explicitly say whether abbreviations are allowed, although the example it gives is for a full name (Ohio). 
> I'm curious about this because the openssl command will create a CSR where stateOrProvince has a two-character (U.S.) state name, and (at least one) CA (Comodo) will happily issue a cert using such a CSR.
I think for ordinary domain-validated certificates, almost nothing in the Subject is actually validated or used by the browser, and I'd guess not inspected by the CA either.
In situations where people actually care, the full name seems to be required for that attribute. The following language shows up in a few places via google:
From the CAB Forum guidelines for EV certs :
> State, province, or locality information (where applicable) must use the full name of the applicable jurisdiction.
From a randomly found ITU-T draft of what became the EV certificate guidelines (TD 0411 , section 8.1.1 (4)):
> State or province or locality information (where applicable) for the Subject’s Jurisdiction of Incorporation or Registration MUST be specified using the full name of the applicable jurisdiction.
My understanding from all this is that the correct use of that attribute is to have the full name, not an abbreviation, but that in most cases, a certificate's subject can contain any old garbage you like and it'll still work for TLS.
For situations other than TLS, of course, it's even vaguer, but I read X.520 as implying that the full name is preferred, but abbreviations may be used as alternatives in directories and so on.
> If not, then maybe it's just a matter of changing the prompt (I'm happy to submit a PR for such a minor change).
I'd argue that the prompt should stay the same. The user can type an abbreviation if they like, but if they're uncertain whether to type an abbreviation or a full name, then it's nice to include that guidance. (The country attribute, in contrast, is required to be an ISO3166 code according to X.520.)