Re: RFC7512 PKCS#11 URI support

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
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-crypto