September 27, 2009 07:05 Nelson B Bolyard wrote: >> To me cluelessness seems to be all over the map since nobody (including >> the people subscribing to this list), have bothered the least about what >> this thingy is supposed do, and how, and why.
> I'm sorry if you feel cluelessness abounds. Let me try to help. You are very welcome! >> I (incorrectly) thought that everybody in computer security knew that >> tokens usually are protected by PIN-codes, but <keygen> does not deal >> with such. > The PKCS#11 model of tokens does not have a PIN per key, but rather has a > PIN per token. Since there are cards with multiple keys and having a unique PIN for each key, I guess the PKCS #11 workaround/mapping scheme is to have multiple slots, where each slot contains a token with a single key? Seen from a <keygen> point-of-view the API should be of secondary interest as long as it can be mapped to achieve the desired functionality. > The PIN size limits (min, max) are not set at the time that > a key is generated but rather at the time that the token is initialized. This is one of the reasons why I play with the idea that key provisioning is a use-case of its own that should be better off with a separate API, and only use legacy APIs for using keys. My current scheme contains about 40 provisioning methods that I think would be more than difficult to get support for in the PKCS #11 community. >> I guess the idea that it is up to the user to decide what the policy >> including selecting "key strength". I have a feeling that there aren't >> too many banks or governments out there that would buy into this. > Have you seen any UI that gives the user a way to make that decision? > It's a decision made at token provisioning time. Banks and governments > provision their tokens with the limits they choose. This is where the <keygen> discussions seem to go wrong. If an on-line provisioning facility cannot set and enforce policies like you can on centrally produced tokens, the motives for using the on-line method becomes zero. >> Don't get me wrong, <keygen> was a necessity for Netscape in order to >> roll out their brilliant contribution to Internet security, the SSL >> protocol. Today the situation is rather different but many solutions are >> still at the 1997 level. >And other proposed solutions are still at the wannabe stage years later. Absolutely :-( However, it is actually much worse than you describe :-( :-( If you do a little EU on-line bank e-government market research you may find what I found: <keygen> and its cousins have in most cases been replaced by proprietary solutions that address *one* provider's policies. Wasn't the USPTO doing something like that on your side of the big pond? I just got this from a Microsoft PM: "From my side, getting the right key or a cert is just half the battle. The lifecycle of that key/cert pair is at least as hard of a problem. For example, if a Bank takes a user through a rigorous process to provision them with a key that is good for let's say a year. How can you renew it later? Do you need to go through the process again? Can your system know ahead of time that they key/cert are about to expire and proactively get another one? What if you don't login to your Bank's website for a while? What do you do when a card is full?" I consider this pretty insightful. Related reading: http://webpki.org/papers/mobilephone-pki-options.pdf Regards, Anders -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
