The API itself may not have been documented, but products using the API
have documented this token:nickname usage. That is the case for some
Oracle server products. Now, I can't say that we really envisioned
anyone entering a URI in the nickname field of our server config files.
It would certainly be unexpected if the server found a cert and came up
in this case. Would we consider it a bug ? I think it's unlikely that
any customer would ever run into this and complain about it. It's not an
impossibility. But this would be borderline user error.
I think there is a difference between extending the syntax of something
like SSL_OptionSet and PK11_FindCertFromNickname .
In the first case, the cipher suite values passed to the API are
normally not exposed to the end-user of the application.
But in the later case, the nickname string often is. Thus, it might make
more sense to create a separate API, that takes a URI as a separate
argument.
Maybe PK11_FindCertFromNicknameOrURI, or something like that.
I also want to mention that there are some fairly major deficiencies in
NSS when it comes to finding certificates. The nickname only represents
a subject. It does not uniquely identify a certificate. Even
token:nickname - which is really token:subject - still does not
uniquely identify a certificate.
There can be multiple certs with different validities, key types, in a
single token. Only searching on a nickname argument, or even
token:nickname, is of limited value, as it does not handle many of those
possibilities. Applications that care about those cases - and server
administrators tend to want to make sure they are using the right
certificate - usually have to write their own cert selection functions.
This is what we have had to do in several products. IMO, the whole
nickname - or token:nickname - is not really precise enough. In cases of
ambiguity, it should either fail, or return a list of certs and private
keys. Then the application could filter that list further. Why cert and
key ? Because there is a single CERTCertificate even a cert/key lives in
several tokens. But there are distinct, slot-specific private key
structures.
IMO, a function that finds a cert with the combination following
criteria would be helpful :
1) token (PK11Slot*)
2) subject (or nickname)
3) issuer subject (or nickname of issuer)
4) serial number
These criteria are necessary to uniquely identify a cert and private key
in a particular token in the NSS world.
This is quite a bit more than just "nickname" or "token:nickname".
Of course, the moment you do a cert renewal, you need to specify the new
cert properly. If you want this to happen automatically, then you can't
use uniquely-identifying criteria. Personally, I believe it is
preferable to have unique identifiers in the runtime. Admin GUIs can be
used to present the user with a list of certs that are fit for a
particular purpose in the application. Beyond that one can come up with
logic to possibly to auto-selection of renewed cert, but the criteria
would likely be application specific. When even the definition of
"CERT_IsNewer" is ambiguous, it's very hard to come up with a one-size
fits all solution.
Anyway, I have digressed quite a bit from the PKCS#11 URI subject at
this point, so I will stop.
Julien
On 4/5/2016 09:49, John Dennis wrote:
One of the problems I have with the argument Ryan presents concerning
API contracts and breakage is that "API contract" Ryan talks about is
to the best of my knowledge undocumented, it's a API "convention"
observed by a select group of developers "in the know". I don't see
anything about a token plus colon prefix in the documentation:
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/SSL_functions/pkfnc.html#1035673
If the API does not have documented behavior constraints then you
can't be causing a API breakage.
P.S.: CERT_FindCertByNickname is also undocumented. Nor is there any
documentation on the syntax of nicknames in Cert DB.
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
