W3C home > Mailing lists > Public > public-webcrypto@w3.org > July 2012

RE: Technology Nexus Web Cryptography API use-cases

From: GALINDO Virginie <Virginie.GALINDO@gemalto.com>
Date: Sat, 14 Jul 2012 12:56:41 +0200
To: Anders Rundgren <anders.rundgren@telia.com>, Samuel Erdtman <samuel.erdtman@nexussafe.com>
CC: "public-webcrypto-comments@w3.org" <public-webcrypto-comments@w3.org>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>, "channy@mozilla.or.kr" <channy@mozilla.or.kr>
Message-ID: <1126F161F6F1B24FABD92B850CAFBD6E0171D40692B2@CROEXCFWP04.gemalto.com>
Samuel, Anders,

Thanks for taking time to discuss your experience with the W3C Web Crypto WG.  Let me share with you few things, related to your discussion based on the use cases brought by Nexus Group (initial mail attached as a reminder).

The use cases related to certificate management (meaning, authenticate with certificate, sign form data, certificate enrollment) do fall into the secondary features of our charter, as suspected by Anders. This implies that it will not be treated as a priority for us, as we already have a huge work to do in 2012 to address our primary features. See our charter here for more information http://www.w3.org/2011/11/webcryptography-charter.html

The use cases related to sign a file, signing uploaded file, storing symmetric key in a protected area are perfectly fitting our primary features on which we are currently working on. As such, we will see how to integrate them into our use case wiki. Channy (CCed) is editing this part of our deliverables and should handle this.

Regarding the crypto providers you are mentioning, the group has started to discuss that possibility during one of our conference call. But at the moment, we are trying to define the different 'properties' of a key and see if this is not enough. In other words, instead of defining where are the key stored, we are defining specific properties of keys (e.g. key is not extractable) and it should be up to the browser to fine the appropriate implementation. We will see if this is enough to address all the possible usage, but we will keep in mind your discussion.

The W3C Web Crypto WG will soon publish the First Public Working Draft - probably during the summer, and thus will ask feedbacks from people like you, willing to use this Web Crypto API. We rely on you to check if this API will be usable for your respective use cases, if failing in our primary features.

Regards,
Virginie Galindo
gemalto
Chair of Web Crypto WG



From: Anders Rundgren [mailto:anders.rundgren@telia.com]
Sent: mercredi 4 juillet 2012 08:21
To: Samuel Erdtman
Cc: public-webcrypto-comments@w3.org
Subject: Re: Technology Nexus Web Cryptography API use-cases

On 2012-07-04 07:49, Samuel Erdtman wrote:
Hi Anders,

Thanks for the comments, Ill try to explain how I was thinking.

Im not aiming to build a complete replica of Nexus Personal, what Im mainly looking for is a common way to access a crypto provider from the browser, and then register e.g. Nexus Personal as a crypto provider to give access to smart cards. This summarizes most of the use-cases that I sent in.

Hi Samuel,
You are not alone asking for this kind of functionality.   I'm personally hesitant to this due to my negative experiences with Microsoft's "CertEnroll" scheme.   The problem (as I see it...) is that cryptographic subsystems like CryptoAPI and PKCS #11 were never designed for access by arbitrary code download from the web.   As an analogy TLS-client-certificate-authentication does its entire job without exposing any API method to the web, only the URL is needed.  Due to this I have essentially lost interest in the Web Cryptography WG; as far as I can tell it won't address "our" applications :-(



I think that Wan-Teh's signature write-up (http://lists.w3.org/Archives/Public/public-webcrypto/2012Jun/0007.html) is a subset of mine. Mine is just a more generalized description of the need for smart-card support, but with a more specific technical description.

Further I wanted to put soma extra focus on signatures in the Web Crypto API which currently have very few use-cases on signing (http://www.w3.org/2012/webcrypto/wiki/Use_Cases).

I wonder if this WG really is properly geared for taking on a web-signature signature application.   It is MAJOR undertaking since you can end-up with anything from crypto.signText() to a 10 Mb+ application!  OTOH, few people are actually interested in this rather esoteric topic so it may pass easy :-)



In the cases where PIN is not supported by the a SoftToken I would imagine the crypto provider either just blindly accepting the request signing it or provide the user with a dialog to accept signing operation.

Yes, however, on the market were we both operate (!), this is not an accepted behavior which is the reason why BankID have (together with NexusSafe I think...) developed specific soft token solutions, most recently Mobile BankID.

Regards,
Anders



Cheers

Samuel Erdtman  |  Developer
Nexus Group  |  www.nexussafe.com<http://www.nexussafe.com/>
________________________________
From: Anders Rundgren [anders.rundgren@telia.com<mailto:anders.rundgren@telia.com>]
Sent: Monday, July 02, 2012 10:13
To: public-webcrypto-comments@w3.org<mailto:public-webcrypto-comments@w3.org>; Samuel Erdtman
Subject: Re: Technology Nexus Web Cryptography API use-cases
Hi Samuel,
I think most the stuff you write about is out-of-scope for the WebCrypto WG.

I don't think that you actually can build applications that mimic the Nexus "Personal" product based on transient downloaded code running in a browser window.

Wan-Teh's signature write-up is though an exception since it is really a complete application:
http://lists.w3.org/Archives/Public/public-webcrypto/2012Jun/0037.html

I have earlier developed a more advanced version of a Web Signature proposal:
http://webpki.org/papers/wasp/wasp-tutorial.pdf
http://code.google.com/p/openkeystore/source/browse/trunk/library/src/org/webpki/wasp/wasp-core.xsd

I'm (nowadays) mainly interested in Certificate Enrollment since the schemes supported by the current platforms are (as I have been banging on peoples' heads about for years) essentially inadequate, in addition to being all-over-the map.  The PIN you are mentioning in your use-case is often not even supported by the underlying crypto system like the NSS "SoftToken".

Best regards
Anders Rundgren
User of Nexus personal, Vendor to BankID, and PKI/Web Technologist.



attached mail follows:


Hi,
I have create a text describing our (Technology Nexus) use-cases. It is a combination of something we do today and what we hope to be able to do with this new API. The text is Wiki formated.

= Technology Nexus Web Cryptography API use-cases =
== Background ==
Technology Nexus is a software company that develops PKI software. In the Nexus product suite there are products for the whole life cycle of certificates, everything from issuing to doing the signing/authentication to validation and revocation. These are products that all has been central to the successful swedish PKI deployment with over 80% of the swedish population using products developed by Technology Nexus.
For the Web Cryptography API a product called Nexus Personal is the most relevant one even though the other ones certainly will be affected by this development. Nexus Personal is a crypto provider that implements the common PKCS#11 interface and the Microsoft CryptoAPI. By doing this Nexus Personal provides smart card access to these interfaces. Further it is well integrated with the browser by plugins for doing application level signatures/authentication from webpages, this is where the new Web Cryptography API would fit perfectly.

== Usecases ==
These are the usecases most central to our current business. As mentioned in the background section there is a focus on signatures.
=== Authenticate with certificate ===
This usecase is quite common for bank customers in Sweden that uses the Swedish BankID for authentication to their internet bank.
* The users enters a web-app (e.g. bank) and selects to authenticate
* The server returns a challenge with a filter to limit selectable certificate to those relevant to this server.
* A javascript picks up this challenge and the filter and asks Web Cryptography API for a signature of the challenge with a certificate that fulfills filter requirement.
'''NOTE''': Here it is important for the javascript to be able to point to a specific crypto provider or a crypto provider with support for certain operations/algorithms. the rational for this is that in sweden we have two major E-ID providers and they do not like signatures from each others clients, i.e. they want to be certain that the signature is done by a certain client. Further this is a usability issue if end user has to select Crypto Provider.

'''NOTE''': Currently we can filter on a combination of:
** Issuer DN (regexp) (can be a way of indicating only certificate on smart card)
** Subject DN (regexp)
** Certificate policy (list of object identifiers)
** Most recently used (i.e. sign with certificate corresponding to most recently used authentication certificat - not relevant for authentication, but for signing
** key usage (normally implied by operation)
* As Nexus Personal is registered as a PKCS#11 provider/CryptoAPI the authentication request gets directed to it.
'''NOTE''': The interaction with Nexus Personal for doing this is today done with a plugin.
* Nexus Personal pops up a dialog for selecting authentication certificate
* If a smart card is attached user can select to authenticate with certificates on it too (if they match filter criteria),
'''NOTE''': Only certificates for authentication is selectable since it was a authentication that was requested (key usage)
* After a certificate is selected by the user Nexus Personal asks the user to enter PIN or if the card reader has a PIN pad the user is asked to use it.
* Nexus personal interacts with the card and create a signature on the challenge
* The signature is returned to the javascript that submits it to the server which validate that the signature is valid for this application.

=== Sign form data ===
In swedish government services and bank services Authentication is seldom enough, before every major transaction of some sort the transaction primitives has to be signed.
* User browses a web-app doing some operations, e.g. filling out tax-declarations, shopping, doing some bank transactions.
* User eventualy clicks finish, but before the operation is executed it has to be signed.
* A javascript creates a string representation TBS (To Be Signed) of the operations to be carried out
'''NOTE''': Most commonly an aggregation of a web form possible compiled together with a template.
* The TBS is passed to the Web Cryptography API with desired signing method and crypto provider reference
* Since Nexus Personal is registered as the crypto provider the signing request gets directed to it
* Nexus personal shows the user the TBS as it is the actual thing that will be signed
'''NOTE''': The TBS contains two parts visible and non-visible the visible part is shown to the user it is formatted to be in good human readable format. Then there is the non-visible part which contains the same information but in a machine readable format. If the transaction is contested it has to be shown in court that the non-visible content corresponds to what the user actually saw.
* User selects among certificates on smart card and certificates managed by Nexus Personal, then the user selects to sign.
* User is asked for PIN either through standard in or PIN-pad on card reader, depending on where key is stored.
* Nexus Personal creates a signature for the TBS.
'''NOTE''': Currently the signature is a PKCS7 or XMLDSIG
* The signature is passed back to the javascript that submits the signature and the TBS.
* Server validates signature and performs form action if signature TBS and form data is aligned with each other

=== Sign file ===
In many cases the user has to consent to agreements of some sort when performing online actions e.g. opening a bank account. And in some cases the user uploads a file that should be signed before it is commited.
==== Signing linked file ====
* User browses a web-app and performs an action needing a digital signature, e.g. open a new bank account.
* In opening this account there is an agreement that has to be signed
* The page contains a link to the agreement pdf
* Javascript creates a TBS, the TBS contains the link to the agreement
* The TBS is passed to the Web Cryptography API with desired signing method
* Since Nexus personal is registered as the crypto provider the signing request is gets directed to it
* Nexus Personal shows the TBS with the link to the file,
* Nexus Personal gives the user the possibility to look at the linked file and creates a hash that is included in the TBS.
* Use looks at the TBS and the file and when satisfied the user selects a signing certificate to do the signing with, the certificate might be managed by Nexus Personal or an attached smart card
* User is prompted to enter PIN either on PIN-pad or standard in
* Nexus Personal creates the signature and passes it back to the javascript
* The javascript sends signature TBS and form data to the server for validation.
* Server validates that all parts of the signature is valid and so on before performing desired action.

==== Signing uploaded files ====
* User browses a web-app and performs an action needing a digital signature, e.g. submitting a homework
* In doing this the teacher wants to know that the submitted homework actually comes from this student, therefor it has to be signed.
* User fills out a form regarding the task and then selects the file containing the homework
* Javascript packages a TBS with the form data and a reference to the file
'''NOTE''': The file reference might be possible to get with the HTML5 FileReader API
* The package is passed to the Web Cryptography API with desired signing method
* Since Nexus personal is registered as the crypto provider the signing request is gets directed to it
* Nexus Personal shows the TBS and the file that will be signed
* Nexus Personal gives the user the possibility to look at the file
* Use looks at the TBS and the file and when satisfied the user selects a signing certificate to do the signing with, the certificate might be managed by Nexus Personal or an attached smart card
* User is prompted to enter PIN either on PIN-pad or standard in
* Nexus Personal creates the signature and passes it back to the javascript
* The javascript sends signature TBS and form data to the server for validation.
* Server validates that all parts of the signature is valid and so on before performing requested action.

=== Store symmetric key in a protected area ===
Technology Nexus also creates a web-based OATH token, this token is currently ran from a native wrapper application. With a secure key store accessible directly from javascript it would be possible to make this client much more lightweight and still achieve desired security. To do this some aspects has to be fulfilled by the Web Cryptography API:
* Keys MUST NOT be possible to extract from key store with javascript, to prevent token theft.
* With a reference to the key it is possible to create a HMAC of a challenge, to generate the one time password.
* Key are protected by same origin policy, to avoid other sites to generate OTPs
* Secure random numbers, to enable secure provisioning (DSKPP)

=== Certificate enrollment ===
A large part of Technology Nexus business is issuing of certificates.
==== Self service ====
This could be for issuing of temporary certificates, in case of misplacement.
* A user has authenticated to a self-service web-portal.
* The users selects to create a certificate.
* User enters reason for issuing and other details required for issuing.
* A javascript asks the Web Cryptography API to create a CSR (or a JSON equivalent)
* Since Nexus Personal is registered as the crypto provider the CSR request gets directed to it
* Nexus Personal generates keys, asks user for PIN and creates a CSR
'''NOTE''': This operation might be passed to a smart card if user selects to use a smart card as media for the key
* The created CSR is returned to the javascript which submits it to the server.
* The server accept the CSR if user is authenticated with appropriate strength.
* Javascript gets certificate back and passers it back to Nexus Personal through the Web Cryptography API

==== Certificat Authority Administrator ====
* An administrator authenticates to the certificate manager web interface, preferable with a smart card ;)
* The administrator enters details for the certificate that he whites to issue
* A javascript asks the Web Cryptography API to create a CSR (or a JSON equivalent)
* Since Nexus Personal is registered as the crypto provider the CSR request is gets directed to it
* Nexus Personal creates CSR and asks for PIN generates keys and so on
NOTE: This operation might be passed to a smart card if user selects to use a smart card as media for the key
* The created CSR is returned to the javascript which submits it to the server.
* The server accept the CSR if user is authenticated with appropriate strength.
* Javascript gets certificate back and passers it back to Nexus Personal through the Web Cryptography API

=== PIN recovery ===
In are organizations it is often required that the user can do some operation of recovery by him self, to lessen the burden of support.
* A user has forgotten his PIN
* He accesses the self-service-portal where he authenticates with some recovery credentials
* In the portal he selects which certificate to recover (server keeps track of his certificates)
* A JavaScript can can now get the PUK from the server
* The script packages this into a PIN recovery request
'''NOTE''': As for previous usecases it is important to be able to specify crypto provider that manages the certificate.
* The request is received by Nexus Personal
* Nexus personal prompts user to enter a new pin and card is recovered

== Additional notes ==
* It is often important for web-apps to be able to filter/search on certificates but it is also important to not give free access to the certificate since it can cantain sensitive information e.g. social security number.
* When doing signatures both attached and detached signatures are desired.


Samuel Erdtman  |  Developer
Nexus Group  |  www.nexussafe.com<http://www.nexussafe.com/>
Received on Saturday, 14 July 2012 10:57:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:11 UTC