On Tue, 2016-04-05 at 17:27 -0700, Julien Pierre wrote: > 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.
This sounds like it's fairly much the use case that we are thinking of, when we suggest that APIs like PK11_FindCertFromNickname() should start to accept RFC7512 identifiers (aka PKCS#11 URIs) too. Firstly, don't get confused by the term 'URI'. It's not "go download your cert/key from the Internet". It's just a string identifying which object should be used, from which existing token. (It's a URN, not a URL. But really, that whole can of worms is best avoided, so think of it just as an 'identifier string'). It's basically identical in scope to the existing 'token:nickname' string. Except for the fact 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. ... all this is mostly solved. You can use any or all of CKA_CLASS, CKA_ID and CKA_LABEL to identify the objects you want to use. (I say "mostly" because it doesn't include CKA_SERIAL_NUMBER which you asked for. I discussed that with the author of RFC7512 (your colleague) a while ago; see http://mozilla.6506.n7.nabble.com/NSS-support-for-RFC7512-PKCS-11-URIs-td339011.html#a33925 ) The idea of the changes we're making (in NSS and elsewhere) is that regardless of which crypto library is being used, users should be able to specify certs/keys/etc. by their PKCS#11 URI in a manner which is consistent across *all* applications. So I'd *expect* your users to put a PKCS#11 URI into your server config file. That is the *standard* form for identifying such objects. And I'd expect them to file a bug if it doesn't work. It's that bug which we're trying to fix, by making it easy (and in most cases a no-op) for NSS-using applications to do the Right Thing. Just like it's trivial with GnuTLS and relatively easy with OpenSSL (now that I've mostly fixed OpenSSL's ENGINE_PKCS11). > Anyway, I have digressed quite a bit from the PKCS#11 URI subject at > this point, so I will stop. I don't think you really have — it cuts to the heart of what we're actually trying to do here. -- David Woodhouse Open Source Technology Centre david.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/MIME cryptographic signature
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
