Since "keygen" & Co do not support smart cards in a reasonable way except for the creation of "administrator cards", I have played with something that is more in line with how *real* card management systems work while still using a browser. The following is an approximation of how this scheme.
After the user surfing/invoking a specific issuer URL: 1. SERVER returns a request containing some intent data which triggers the BROWSER to show a specific "keygen" acceptance dialog 2. If the user accepts the request, the BROWSER responds with some capability parameters. The dialog remains open although it changes contents to "Creating Keys" or similar and the browser window enters "protocol mode" 3. The SERVER returns a provisioning session creation request 4. The BROWSER responds with shared and attested session token (created in the *card*) which is used throughout the process to achieve confidentiality for downloaded secret data (PINs, restored private keys, symmetric keys) as well as vouching for integrity of data 5. The SERVER returns a key-pair creation request if the response in #4 is accepted (based type of card, or on actual unit) 6. The BROWSER responds with freshly created and (by the session token) *attested* public keys 7. The SERVER returns with certified keys 8. The BROWSER responds with a attested provisioning result for the entire session. The dialog closes and the browser window returns to "web mode" Not in the protocol: The SERVER returns ordinary web content telling the user that the process succeeded or not. SERVER request = HTTP body, BROWSER response = HTTP POST Putting this kind of functionality in an API like generateCRMFrequest or an HTML element like <keygen> seems like a very difficult task. The described scheme is more related TLS since all but the initial request is performed in managed browser code making it possible to perform sensitive operations behind the curtain rather than exposing a cryptographic API to arbitrary web code. Secure sessions (card-2-issuer) is pushed by the card vendors as the next step and is in fact already featured in Microsoft's ILM so this is NOT research, it is doing it in a browser that's missing. Very little of this fits in PKCS #11 which may be seen as an obstacle. I personally do not believe this is a problem; PKCS #11 is fine as is, it does not need to be changed but supplemented by a *provisioning API*. I left out an optional request-response key management step for brevity. The only real problem I have seen is privacy-related. According to TrustedComputingGroup the identity of the card container is highly privacy impeding since it is "certified". IMHO, an e-mail address represents a bigger threat even though it is (usually) not certified. I don't have any silver bullet to offer and I don't see that there is a need for one either but that's of course for the "market" to decide :-) Anders -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
