Currently the Subject: O and OU fields (and presumably a lot of others) are blank or not provided because the CA does not have a way to verify that information. That is fine, but it is really overkill. It would be nice if data could be stored in those fields with a clear indication that it has not been verified. So how about allowing them in this form:
O CLAIMS_TO_BE Some University
OU CLAIMS_TO_BE Physics Division
etc.
It does not have to be “CLAIMS_TO_BE” of course, “NOT VERIFIED”,
“???”, and many other variants are possible.
Why? Because sometimes it is not at all clear where a URL has actually landed, and examining the certificate can provide that information, or at least hints about it. Obviously if one saw a link like that for a financial or health site one should run screaming for the exits. But why not allow it for academic sites? This would be mostly for figuring out who to contact, when necessary, when that information is missing from the web page, or that page is out of date or copied from somewhere else. If somebody sees
O CLAIMS_TO_BE Bank of America
and goes ahead anyway, they will get what they deserve.
It’s outside the purpose of a certificate for you (the subscriber) to convey arbitrary information. You can put that on the website or in your domain registration info (WHOIS/RDAP).
The information in a certificate is limited to what an issuer/CA can actually attest to.
I guess an analogy would be the situation with doctor’s notes - we don’t want a situation where you’re coming into work after an absence with something that says “patient reports that they feel too unwell to work”.
I think the CLAIMS_TO_BE text would also run a risk of confusing relying parties who didn’t speak English, especially when the rest of the text in the fields weren’t in English. Consider strings like
O = CLAIMS_TO_BE Ministério das Relações Exteriores O = CLAIMS_TO_BE 日本銀行
Or, imagine this from the other point of view!
O = AFIRMA_QUE_E Bank of America O = LAUTEIGENENANGEBEN Citibank
I fear that the non-Portuguese-speaking user may assume that the AFIRMA_QUE_E is some kind of X.509 jargon or abbreviation on par with the O =, rather than an attempt to qualify the semantics of the string that follows. Similarly, the non-German-speaking user may gloss over LAUTEIGENENANGEBEN rather than trying to parse it into words.
While this kind of risk might be relatively low or might be confined to relatively specific circumstances, I think the CA industry overall would conclude that it outweighs the advantages of communicating what @_az referred to as “arbitrary information” about subjects’ unverified assertions.
One could argue that similar arguments expose risks in other existing uses of X.509 subject data, but in any case the CA world is very reluctant to create new risks just because there are already various risks out there in the existing PKI.
A downside of the question mark is that it was the universal “unprintable character” substitution until browsers and apps started implementing the actual Unicode replacement character. If I saw multiple question marks like that, I’d assume it was unprintable characters or a bad Unicode conversion.
