Web Crypto API Community Group

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.

MOTIVATION
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

Key Store
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:
function showUserCert()
{
// select user certificate to login from keystore
var key = new webcrypto.getUserCert();
for (i in key)
{
// make user interface to choose key for login
}
}

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.

Problem Statement

While OAuth has solved the authorization problem, currently authentication on the Web is still insecure as it has yet for the most part failed to go beyond user-names and passwords. However, at this point a number of new client-side capabilities, including the possibility of W3C standardized Javascript cryptographic primitives, are emerging and a number of specifications such as OpenID Connect, BrowserID, and discussions over the future of HTTP Auth have shown that there is interest in understanding better how client-side key material can be used to enable a more secure Web authentication. However, there has yet to be consensus on how client-side cryptography can enable higher-security OAuth flows. The purpose of this side meeting is to look at a more coherent picture of how technologies in the space of identity, authentication, and authorization combine and interact and to help frame future work in Web authentication.

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 (hhalpin@w3.org)

2011/12/8 Anders Rundgren
> This use-case (in order to be meaningful) covers all aspects of a key's life:
> from enrollment, to usage, renewals and revocation.
This can be separated primary and secondary area. Mos impoartant part of
Korean use-cases is generationg of *digital signature* with user
certificate in anywhere. Key management can be served by third party
extensions or oneself in key manament option in browers.
> I do not think this group is properly equipped to deal with such a wide scope
> but if somebody wants to take it up, please do!
If someone can afford to try to do, I think it can be do this in working
group too. Many crypto-geeks can be volunteers. BTW, where is VeriSign? :)
> Experiences from other consortium's like the Information Card Foundation
> indicates that the interest in publicly dealing with on-line banking technology
> is moderate; it has always been a "consultant paradise".
You're right. There are many companies to support banks technically in
Korea too. But, many counties have already "law" for digital signature,
http://en.wikipedia.org/wiki/Digital_signatures_and_law. It means it's
standards area in web applications too.
Channy

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.

The signing and verifying Javascript code libraries can be used to determine their trustworthiness.

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 usedcertificate 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.

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.