Re: RFC7512 PKCS#11 URI support

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
[email protected]                              Intel Corporation

-- 
dev-tech-crypto mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-crypto