Robert Relyea wrote: >> What I was referring to is the inability for an issuer specifying that >> generated keys should be PIN-protected and what constraints >> there should be on the PIN while still optionally letting the user >> specify the actual PIN. <snip>
>In general we have been reluctant to add attributes to either keygen or >the crypto.crmf() interface that gives requirements that either 1) the >browser verify enforcement, or 2) that the server can't verify >enforcement. I believe these principles are worth clinging to because they're good! <snip> >Your case, however seem to be more of a 'policy hint'. A "please put >this key only in a PIN-protected token". That case is more reasonable >because the server doesn't have to depend on the browser telling the >truth. You are only trying to protect the naive user (who is unlikely to >build his own modified browser) After all, the sophisticated user can <easily extract the key later and insert it in a non-PIN-protected token >(or even remove the PIN protection after the key is imported). This is not exactly what I'm working with or suggesting. It is true that initially you cannot do anything but *hope* that your "hint" or whatever mechanism you used to point out the key storage module is honored. However, after receiving the response there are methods supported by TPMs that can be used by the server to cryptographically verify that the keys were generated in the TPM. See my posting "SmartCards Support" for details. Embedded TPMs will be standard in mobile phones because the add-on cost is close to negliable and you anyway need HW keys in order to protect the OS when phones morph into small PCs. PC processors will get on-chip TPM support even sooner. Updating the KeyGen tag for this scenario seems undoable, you need something considerably more sophisticated which also allows some features to be stepwise adopted such as ECC keys. Don't worry, KeyGen will not die, it will just get "smaller" :-) Redhat and Mozilla is BTW much welcome with input. Maybe you could comment on the following? http://webpki.org/papers/web/XMLBrowserExtensionScheme.pdf Regards Anders _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto