During the Netscape heydays <keygen> was probably pretty OK. However, that was a long time ago.
In fact, <keygen> only meets a single of the dozen+ imaginable features outlined here: http://webpki.org/papers/PKI/certenroll-features.pdf For the PC platform which seems to resist all modernization efforts in this space (probably due to the "Wintel" hegemony plus the inability of the smart card community creating anything "Internetish"), there's little point in upgrading stuff; this request is dedicated to the always connected, mobile devices which primarily rely on embedded platform capabilities. Although swapping <keygen> for something else has indeed been proposed. IMO, that wouldn't help much because the underpinnings like "KeyChain" is also in need of renovation. The somewhat bigger question is thus whether "KeyChain" should be upgraded or if it (as I propose) should be "complemented" with *another* API for provisioning. The primary reason why I think the latter is a better idea is that credential provisioning security-wise should operate "one level down" in the stack compared to credential usage. Proof: The Google Wallet doesn't utilize on "KeyChain"/<keygen>-like technology for provisioning, it rather builds on (according to unverified sources...) GlobalPlatform's SCPnn. Anders -- You received this message because you are subscribed to the Google Groups "Android Security Discussions" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/android-security-discuss?hl=en.
