This group discusses Web Crypto APIs for signing the message by the user certificate issuing from the certificate authority for SSL communications. It is based on http://html5.creation.net/webcrypto-api/
Note: Community Groups are proposed and run by the community. Although W3C hosts these conversations, the groups do not necessarily represent the views of the W3C Membership or staff.
Tomorrow (Monday) W3C Web Cryptography workgin group will be doing a public telecon. This will most useful for those who are new to W3C process or are interested in the Working Group and are considering joining but have questions about the charter/scope.
Over 15 million personal certificates are issued and renewed in every year in Korea. But this certificate service has been offered using ActiveX based plugin technology. As a result, Korean people couldn’t choose other browsers not to be supported plugin by bank, shopping and governmental sites. (It’s not only Korea but also many countries with national certificate authority such as European and south American countries too.)
Some of discussions has raised in this topic in WHATWG, HTML w/g and Webapps W/G since 2008.
Korea’s browser monoculture has prevented tech innovations and user’s choice. It was caused by wrong implementation of digital signature by Korean gorvenment’s the law and national PKI system. Its technique has been based on browser plugin as like Active X and Java applet, so it also made many security problems on user’s PC. Nowadays 15 million personal certificates were issued and they are used in e-banking, trading and governmental sites to valid user and transaction in Korea.
Similarly some of European countries also had national PKI system including Denmark, Spain and etc. Denmark’s system was opensourced, but it is also based on browser plugins. It were dominated by VeriSign most of commercial market as like private CA service with issuing personal certificate and transaction with digital signature. SUMMARY
Korea like to implement to replace plug-in based certificate service to JS based applications running in a browser or other HTML/CSS/JS-based platform between banking and public certificate servers. It may be included TLS session login/logout, key import/export, a common method for accessing and defining properties of keys, and the lifecycle control of credentials such enrollment, selection, and revocation of credentials with a focus enabling the selection of certificates for signing and encryption. DETAILS
This document assumes the availability of key store in the browser or browser framework. A <MyCertificate> saved in “key store” may be not made by domain based personal certificates and can be imported from HTML5 file API, third party application or user’s action in browser. Login/out with Certificate
If an user has own a certificate issued by certificate authority, the user can offer his/her credentials to web sites and get some of authorities by login process.
// In this example, we use the following webcrypto APIs:
The webcrypto.login generates safe encrypted messages and directly sends to web server for validation and authentification. After that, server responses to client whether user certificate is validated or not. Transation Security
Each transations by webcrypto based methods should not permit DOM changes by other JS functions to protect integrity of keystore and messages. Signing messages
The webcrypto.signText method generates digitally signed encrypted messages by selected the user certificate given text strings. When the signText(“stringToSign”, keyname, signOption) method is invoked, the user agent must run these steps:
Let stringToSign be the string that the user want to sign. It can be the string, json or XML format. If stringToSign indicates document ID for specific form, the user agent generates QUERY_STRING variables from form.
Keyname must be used in login process or you can let user choose other certificate by showUserCert().
Import and export Keystore
This webcrypto.importKeypair method import a key pair into a keystore from PKCS #12 or PEM bundle file.
The user selects the folder where the required PKCS #12 or PEM bundle file is stored and clicks on the required PKCS #12 or PEM bundle file.
If the selected file was a PEM bundle containing encrypted private keys, one or more Password for Private Key dialogs will appear, one fore each such key.
The method can call directly the native user interface of the browser specific function for importing keypair.
Issue on key protection
In Korean bank cases, each private key is encrypted again with user’s pass phase because of multiple key selection by multiple users on a computer. For login in bank site and signing money transaction, user can choose own certificate in multiple of key store and input passphase.
Actually my computer is used my daughter and visitor in my home and we cannot suppose that my computer is only used by myself. If key store is used on financial transations, it must be considered as human factor in real world. REFERENCES
Beyond HTTP Authentication: OAuth, OpenID, and BrowserID
Time and Location
March, 29th 2012 Thursday lunchtime (1130 to 1300) in room 252A just between the SCIM BoF and OAuth WG as part of IETF83 in Paris.
This informal meeting will present a number of proposed technical proposals in brief, including relationships to other existing work (such as RTCWeb and the upcoming W3C Web Cryptography Working Group), and to help frame future work in the area.and then precede with open discussion.
For any questions, please contact Harry Halpin (email@example.com)
11:30-11:45 Lightning presentations to “level-set” participants.
Mike Jones (Microsoft) will present the latest work from JOSE and OpenID Connect
Eric Rescorla (Mozilla hat on) will present Mozilla Persona and RTCWeb/WebRTC work
Blaine Cook will present OAuth 2.0
Harry Halpin (W3C) will present the upcoming W3C Web Cryptography API.
11:45-13:00 Open discussion on co-ordination between OAuth, HTTP Auth, OpenID Connect, BrowserID, and W3C.
The ability to select credentials and sign statements can be necessary to perform high-value finanicial transactions as well as secure identity-related claims personal data.
The provisioning and use of keys within Web applications can be used for scenarios like increasing the security of user authentication and to determine whether a particular device is authenticated for particular services.
Encrypting local storage (via sharing the key identifier with the server to decrypt when needed) can make valuable information therein more secure.
The encryption of user communication such as near real-time messaging via Web applications.
In case of a bill of credit card or telephone or personal medical data from hospital, the encrypted messages can be secure because anyone cannot see that. In Korea, many credit card companies and tax agencies send bills to customers via email attachement. Users can see it by their certificate. – little weired 🙁
Most of credit card transaction has been based on card number, expire date and CVC code. Recently VISA3D was developed similar with pin code. But, permantly, user certificate issued by credit card is more secure than previous methods. In Korea, major card companies have already used certificate based card transations.
Most of company used SSL based VPN with pre-installed agent program, but the method of authentification is just pin code or one-time pasword. Certificate based VPN in web will be good market to many security companies and useful to users.
Some of contents can be paid by users and web developers can determine users and devices too. In that process, maintaining SSL servers for all of web contents are very big burden for IT companies. Web developers can treat only selected contents with light secured methods.
I want to add some of use-cases too.
1. Handling S-MIME certificate and encryption and decryption in web based email system. It’s very important problem for company based secret deals between internatioanl companies.
2. Handling XML Encryption via SOAP in web application. Despite of small cases, there are still SOAP based XML communications in govenments and big companies. This naturally can be migrated to web applications.
It was added “secondary features” and “out of scope”.
The primary features in scope are encryption, decryption, digital signature generation and verification, hash/message digest algorithms, confidentiality algorithms, key transport/agreement algorithms, HMAC algorithms, key pair generation, and key storage on the device. In addition, the API should be asynchronous and must prevent external access to secret material.
Secondary features might include: strong random generation, control of session login/logout, extraction of keys from TLS sessions, PKI scheme validation, destruction of temporary credentials, storage of secrets in a tamper-proof container.
The following items are out of scope: key identifier naming schemes (thus implying that key identifiers are in general opaque), information about the provenance and destination of a key, access control beyond enforcement of the same-origin policy, multi-key collections, binding various human-oriented identifiers to keys, management and validation of certificates, and device-specific access to keying material.
Secondary features include my favorite features of Web Crypto API draft except hardware handling such as HSM and smart card.
Now many discussions are goning on scopes of Web Cryptography working group charter. I think many of use-cases in cryptography API focused in certificate authority service with personal certificates.
But, this is hard to consider another working group because of PKI based systems too. (Most of countries has own national CA system based on plug-in issuing personal certificate such as China, Japan, Spain and Brazil etc.) So I suggested adding parallel works for *Web Certificates (Service)
API* supporting these. We can add these as a scope including TLS/SSL based login/out with personal certificate and its management api(backup, restore)
and follow up HSM based certificate.
Especially in Firefox, the validation of security device based on FIPS is already possible. (Other browser?) I guess Web Certificate Service API is needed to treat this kind of interfaces in future. Anyway we have better focus on primitive APIs for light-weight usecases. Because all browsers have own key stroage. 🙂
Please give a comment for my suggestions: