FYI. Slightly edited from discussions in other lists... Background: The 15Y old Netscape hack known as "<keygen>" has been suggested as an HTML5 standard. I maintain that it is close to useless.
>> A guesstimate is that less than 1 out of 10 000 smart cards actually >> are provisioned with <keygen>. > Can you backup your statement with facts please? I wrote "guesstimate". However, if we exclude a limited number of security nerds (that mainly produce cards for themselves) or extremely low-volume production, and concentrate on REAL smart card deployments; you got about a million eID cards in Estonia, None of these were provisioned using <keygen>; they were presumably produced in some kind of card factory. For enterprises most of us know that Windows is the de-facto standard so even if they had actually used end-user provisioning, it would have been through Xenroll and CSPs rather than with <keygen> and PKCS #11. But why in the would anybody seriously consider end-user provisioning with <keygen>, Xenroll, or generateCRMFRequest, for provisioning smart cards when: - you still have to do 80% of the gory stuff (formatting, PIN, PUK) in a Windows-only proprietary card management application? - all bets are off regarding where keys actually were created? - it introduces very awkward distribution of enrollment passwords? That is, <keygen> is left for "soft certificates" that by default are not even PIN-protected. In my vocabulary that spells "insignificant". Anders _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
