> Sorry to ask so many questions, but I am a little bit lost to identify > the minimum requirement of a PKSC11 token to supprt NSS/TLS.
I will try to answer some of your questions. I work with Bob (sit next to him). Hopefully my answers will not contradict his, but will come from another perspective.
The direct answer to your question is as follows:
To support SSL/TLS client authentication only, the minimum requirement is to do CKM_RSA_PKCS signatures.
If (as you suggest in previous emails) you wish to keep all the deriving of master and pre-master secrets in the token, Your token must support the following mechanisms:
For ssl3 and/or TLS:
CKM_SSL3_PRE_MASTER_KEY_GEN (used for SSL3 and TLS)
CKM_RSA_PKCS
for SSL3
CKM_SSL3_MASTER_KEY_DERIVE and
CKM_SSL3_KEY_AND_MAC_DERIVE
CKM_MD5 and CKA_SHA_1, including digesting the master secret
(as a key) into MD5 and SHA1.
for TLS (note: NOT WTLS)
CKM_TLS_MASTER_KEY_DERIVE
CKM_TLS_KEY_AND_MAC_DERIVE
CKM_TLS_PRF_GENERAL
If you want the SSL/TLS session cache to work, allowing SSL sessions to be re-established without doing a Full RSA handshake everytime, then you also need the following: a) some mechanism for wrapping and unwrapping the master secret b) a key gen mechanism for generating a key for that wrapping, on your token.
That key will be used to wrap and unwrap master secrets for storage in client memory.
> I am a little bit confused about the usage of an hardware token for TLS > handshake. I do not understand why it has been included in WIM > definition, if it does not bring more security.
dunno about WIM or its motives.
Keeping the master secret in a token means that without that token, no-one can restart any SSL sessions established with that token. That's probably the motive.
> I have understood that server is not aware if client use a softtoken or > an hardware token. > I am working in mobile terminal environment, and I have not yet study > the impact to support TLS PRF function in software (RAM,ROM,MIPS). > Is the software random of NSS compliant with TLS PRF definition
> I have notice, that current NSS version use CKM_TLS_PRF_GENERAL > mechanism, but new PKCS11 version 2.2 refers CKM_TLS_PRF using specific > parameters.
NSS doesn't use the new CKM_TLS_PRF. It uses the older CKM_TLS_PRF_GENERAL.
> SSL module uses CKM_TLS_PRF_GENERAL, should we map it on CKM_TLS_PRF
If you can implement CKM_TLS_PRF_GENERAL using an underlying implementatino of CKM_TLS_PRF, go for it. :)
> I was not able to find any reference to CKF_RANDOM definition nor in NSS > code, nor in PKSC11 standard definition. Where should i clain supporting > random generation.
I think Bob meant to write CKF_RNG.
> For my first demonstration step I do not need to create a TLS client > compatible with all tokens types such FIPS. I have only to demonstrate a > TLS connection with server and client authentication, using RSA key > exchange method and one cipher suite (RC4 is fine). I would like to > investigate impact of using a WIM. > > Mozilla try to find this object on our token? What is this object class? > is It a specific NSS object classe.
> CKA_CLASS Value CE534354 not found for type CK_OBJECT_CLASS
Yes, You'll notice that value is 0x80000000 (which is CKO_VENDOR_DEFINED) or'ed with the ASCII letters "NSCP" + 4. That's NSS's vendor-defined object class 4. CKO_NETSCAPE_BUILTIN_ROOT_LIST
You should handle it the way you handle any search for an unrecoginzed object class type.
> When NSS/SSL fails to do an action with a slot, does it try with an > other slot or an other token, which supports all the required mechanism ?
Depends on what it's trying to do. If NSS is trying to do somthing that requires a key (which is in a particular slop/token), and that operation fails, then no, NSS will not try another slot. In general NSS tries to find the right slot in which to do an action, and then tries it there.
There are a few exceptions where NSS falls back to other methods. Unwrapping may fall back on trying to do a decrypt, for example.
> In which case NSS/TLS need to create secret, private key objects?
Secret key objects, like the pre-master secret, are generated as needed.
private key objects are generated to do key exchanges with FIPS tokens, and may be generated as part of token mechanism verification. These would be so-called "session objects".
> In which case NSS/TLS need to unwrap key and decript? when temporarily > key are used?
SSL/TLS defines the use of a cache of session keys (that is, of master secrets). NSS attempts to get the token to wrap each newly created session key (using a wrapping key known only to that token), so that the wrapped master secret may be safely extracted and cached.
-- Nelson B
_______________________________________________ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
