Re: PKCS#11 platform integration
On Sun, 2015-05-10 at 12:47 -0700, Ryan Sleevi wrote: - Don't load a module unless the user has explicitly asked or configured that module to be loaded. - Do not patch NSS to load modules outside of the explicitly requested modules. Quite right; that's absolutely how we should behave. As long as we include the sysadmin as a 'user' in the above definition, of course. The sysadmin should be able to configure things for *all* users according to the desired policy, rather than forcing each user to set things up for themselves. And in turn the *developers* of the operating system distribution should be able to set a default policy for the sysadmin to build upon. I mention that because it cuts to the heart of what we're actually trying to achieve here — being able to set a *platform* policy which is then honoured consistently by all applications regardless of which crypto library they're using today. Note that in the case of p11-kit, the policy you set is already a per -application choice. You can set a module to be loaded in one application, but not in another. Which is something that AFAIK you *cannot* do with a shared NSS database in $HOME/.pki/nssdb. I completely agree that Chrome should only ever load the modules which are configured to be loaded into Chrome. I'm surprised you feel the need to mention that. -- dwmw2 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
Re: PKCS#11 platform integration
David Woodhouse dw...@infradead.org wrote: The sysadmin should be able to configure things for *all* users according to the desired policy, rather than forcing each user to set things up for themselves. And in turn the *developers* of the operating system distribution should be able to set a default policy for the sysadmin to build upon. Actually, this is the opposite of Firefox's policy. Firefox *intentionally* doesn't do that. It may be possible to hack things to make it work (I believe RHEL and Fedora do something like that already, for example), but those hacks violate the spirit, if not the letter, of the Firefox trademark policy regarding unauthorized modifications of Firefox. And, also, AFAICT, those kinds of hacks may stop working at any time. Said differently, there is nothing special about Linux. Just as Firefox intentionally doesn't use Windows's central certificate trust database on Windows, and just as it doesn't use Mac OS X's central certificate trust database on Mac OS X, it shouldn't use a Linux distro's central certificate trust database. Put yet another way, it is basically Mozilla's policy to make sysadmins' and Linux distros' jobs difficult in this area, because doing so is sort of required for Mozilla to maintain autonomy over its root CA inclusion policy. Thus, fixing this kind of problem is actually harmful. That said, of course it would be nice if smart cards and client certificates worked automatically, but those improvements need to be in such a way that they wouldn't change the trust and non-trust of server certificates. Cheers, Brian -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: PKCS#11 platform integration
On Mon, May 11, 2015 4:09 am, David Woodhouse wrote: I completely agree that Chrome should only ever load the modules which are configured to be loaded into Chrome. I'm surprised you feel the need to mention that. Because you still don't understand, despite how many ways I'm trying to say it. It's not simply sufficient to load module X into Chrome or not. p11-kit's security model is *broken* for applications like Chrome, at least with respect to how you propose to implement. Let's say you've got Module X. Today, Chrome controls loading of modules. It can load module X into the browser process (and trusted process) and *NOT* load Module X into a sandboxed zygote process that it then uses to start renderers and such. Because Chrome fully controls module loading, and uses the NSS documented APIs, it can ensure that things are appropriately controlled. It can guarantee exactly which modules can be loaded into the untrusted process - such as the read-only, non-modiable root trust module. You still don't seem to understand that distinction, because you keep calling it broken. No, it's only broken with something like p11-kit comes along and violates the API guarantees. That's why I keep reiterating that the reasons for NSS's per-application config extend beyond just No one's gotten around to it and are deeply intertwined with *legitimate application's needs that p11-kit so far fails to respect. I don't know how many ways I can say it, but I'm trying to provide a simple example that can be empirically validated about how your proposal *fails* and causes security issues. I think you keep leaping ahead of yourself in proposing, so I would again, as I have privately, encouraged you to go back, start from first principals, and make sure you *understand the requirements* before jumping too far into proposing solutions. I think a solution can be found, but I think we're going to continue to waste time if every other email jumps three steps ahead. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: target parameter to PK11_Derive
On 05/07/2015 11:49 AM, Andrew Cagney wrote: [inline] On 5 May 2015 at 13:18, Robert Relyea rrel...@redhat.com wrote: The target Mechanism is the operation you are going to use the target key for, It shouldn't match the mechanism used to derive the key. It is basically used to set the appropriate key type and flags on the resultant key. Example psuedo code: key1 = derive(keybase, mech=CKM_XOR_BASE_AND_DATA, target=CKM_SHA1_KEY_DERIVATION, data); key2 = derive(key1, mech=CKM_SHA1_KEY_DERIVATION, target=CKM_AES_CBC, NULL); decrypt(key2, mech=CKM_AES_CBC, input, output); Ideally you should try to keep it consistent with how your are planning on using the key, but in practice as long as the key is basically the same kind of key, the extact value of target is not necessary (You can use a key generated with target CKM_AES_CBC on an CKM_AES_ECB operation, for instance). Target may also be used to try to set the appropriate key length (if key length isn't supplied). Thanks for the clarification; my reading of the documentation wasn't too far off. For the intermediate values I think I'll try something like CKM_VENDOR_DEFINED; and, to your point, ensure all the final keys have meaningful values. I'm not sure CKM_VENDOR_DEFINED will be the right thing. The intermediate values are likely CKK_SECRET_KEYS with CKA_DERIVE set to true, It's probably best if you want to use the same value to use something like CKM_XOR_BASE_AND_DATA or something similiar. bob 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
