Skip to toolbar

Community & Business Groups

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/

Group's public email, repo and wiki activity over time

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.

drafts / licensing info

name
Web Crypto API — An Authentification of Data and People in SSL

Chairs, when logged in, may publish draft and final reports. Please see report requirements.

This group does not have a Chair and thus cannot publish new reports. Learn how to choose a Chair.

A draft of WebCrypto use cases

I gathered candidates of webcrypto use cases in our wiki page: http://www.w3.org/community/webcryptoapi/wiki/Use_Cases. If you have any comments and addings, please don’t hesitate to edit this page.

As following is list:

    1 Use Case Index
        1.1 Primary features
            1.1.1 Secure messaging
            1.1.2 Encrypted web applications
            1.1.3 Storing local storage
            1.1.4 Encrypted bill
            1.1.5 Client authentifications
        1.2 Secondary features
            1.2.1 Financial Transaction: Online bank
            1.2.2 Credit card process
            1.2.3 SSL VPN
            1.2.4 Handling S/MIME mail
            1.2.5 Handling XML Encryption
        1.3 Etc
        1.4 References

First Draft of Web Crypto API — An Authentification of Data and People in SSL published by Web Crypto API Community Group

On 2012-05-07 the Web Crypto API Community Group published the first draft of the following specification:

Participants contribute material to this specification under the W3C Community Contributor License Agreement (CLA).

If you have any questions, please contact the group on their public list: public-webcryptoapi@w3.org. Learn more about the Web Crypto API Community Group.

The first telcon of WebCrypto W/G

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.

Please join us:

Introductory teleconference (public): May 7, 2012
1500 EDT (1900 UTC) +1.617.761.6200, 27978# (CRYPT)
IRC irc.w3.org:6665 #crypto

You may want to look at the homepage and the charter beforehand:

http://www.w3.org/2012/webcrypto/

As well as a draft API:

http://www.w3.org/2012/webcrypto/WebCryptoAPI/

A draft of Korea WebCrypto UseCase

I started a draft of Korea WebCrypto UseCase. If you’re interested in financial transations with web cryptography API or Korean experts for security areas.

Wiki page: http://www.w3.org/wiki/KoreaWebCryptoUseCase

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
  }
}

// If the user choose one key,

function login(keyname) {
  var chosenKey = new webcrypto.viewCertInfo(keyname);
  var response = webcrypto.login(chosenKey);
  if(response.code = 200) login_process()
}

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

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)

Schedule

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.

“Korean bank” use-case – Rejected?

As following is my reply for “Korean bank” use-case – Rejected? by Anders Rundgren. In conclusion, I think new charter includes Korean usecase too.

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

Use-cases for Web Crypto API

There is several use-cases for web crypto api. Harry Halpin wrote:

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

Also I suggested some of things in mailinglist:

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.

New HTML version of Web Cryptography Working Group charter

According to Harry Halpin, there is a new HTML version of chater.

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.