David,
On 4/6/2016 05:57, David Woodhouse wrote:
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.
Except that CKA_ID does not uniquely identify an object of any single type.
Even if it did, you would still need to uniquely identify the token
first, and combine it with one or more of those other attributes.
Seems like the PKCS#11 URI support is supposed to be that unique ID.
So, you need a string like :
token_identifier : pkcs_uri
And have the CKA_CLASS be implicitly set to certificate, and then the
application can just look for the corresponding private key, in the same
token - .
But you would still have to define the format of the string this way in
your application . It could be two separate strings, one for token and
one for ID, or a combination string, or something else.
The existing usage for the nickname string in those apps is not defined
that way, though. Trying to change it may result in unexpected behavior.
)
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 would only be a bug if the application claimed to comply with that
RC, which obviously can't be the case for applications that predate it.
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).
Well, it isn't going to be a no-op. I think it would be best to have a
new, well-defined API to uniquely identify a cert, rather than try to
fit the new scheme into existing APIs that run into ambiguity and
sometimes make strange and unexpected choices, choices that may not be
what the application expects.
Some applications use PK11_FindCertFromNickname, and others don't.
The API call is really treacherous in what it does, and the results are
really not well-defined in ambiguous cases - for example, if a cert and
key exists in multiple tokens.
For this reason, in iPlanet web server, I wrote an alternate version of
this call that better suits the needs of the application. This is
really old code, maybe 15 years or so.
You take a look at it at :
https://github.com/jvirkki/heliod/blob/master/src/server/base/sslconf.cpp#L175
https://github.com/jvirkki/heliod/blob/master/src/server/base/servnss.cpp#L860
Gory details, I know, but the point was to deal the possibility of keys
and certs in multiple tokens, and the CERTCertificate's unique slot
pointer pointing to a different slot than requested in the
token:nickname string, if the private key in several places.
So, regardless of what changes you make to PK11_FindCertFromNickname or
not, it's not going to make this scheme work in iWS (or OTD 11g).
The proper way would be a new API, explicitly defined, and for
applications to make proper use of it, and define the string fields in
their config files appropriate to their own needs. I'm speaking as both
application developer and former NSS developer, here.
Of note, also, is that not all applications are strictly PKCS#11
exclusive. Certs and keys can sometimes live in other stores that are
not managed by PKCS#11 module. Not in NSS applications, mind you, but
such applications are out there.
PKCS#11, and the layers on top of it, is inefficient in terms of
runtime. Most accelerator vendors, and even some HSM vendors, have
completely given up support for PKCS#11 for this reason. IMO, trying to
design a "universal" configuration string in a world where not all
applications are PKCS#11 is doomed to fail. OTD 12c for example does not
use NSS and does not support PKCS#11, and has moved away from the
token:nickname string. It uses PKCS#12 wallets as keystores, and a
triplet of "subject:issuer:serial" as the identifier for certs and keys.
Only subject is required, issuer and serial are optional. Unlike
PK11_FindCertFromNickname, if there is any ambiguity, the server does
not choose an arbitrary cert and key based on guesses of the library,
but instead fails to come up and asks the administrator to correct the
ambiguity by uniquely identifying the cert and key it actually wants to
use (and it lists all of them if log is verbose, also). PKCS#11 support
may be restored at some point in the future, and at that point, we would
probably add another field to identify the token.
I'm not completely sure if an RFC is the right place to try to dictate
the needs of applications, to be honest. But if there is going to be a
standard, IMO, at least, it should account for the possibility that
cert/keystores other than PKCS#11 exist.
Julien
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
