Fwd: [Moderator Action] RE: Suggestions for Web Crypto WG next steps

Wahaj Khan,

I've forwarded this to public-webcrypto-comments@w3.org, which is the
right public mailing list for this discussion. public-webcrypto@w3.org
requires WG membership. cheers, harry

-------- Forwarded Message --------
Subject: [Moderator Action] RE: Suggestions for Web Crypto WG next steps
Date: Wed, 11 Mar 2015 10:30:43 +0000
From: M Wahaj Khan <wahaj.khan@ascertia.com>
To: public-webcrypto@w3.org

Support point 2 and 5 below; while Java is not recommended in Chrome and
soon to be blocked for good by Google
(https://java.com/en/download/faq/chrome.xml), there seems no technical
choice for Chrome users on how to use platform specific user keys to
perform actions like document signing via Chrome. This is definitely
good for users who don't have smart cards to protect their keys on the
system while still want to use their digital certificate to perform
crypto operations. These keys would be of course protected by the
underlying OS. Point 5 would then help this use case by allowing users
to import their existing PKCS#12 files via Web Crypto and hence later
use it.
While applets are blocked in Chrome, my understanding is that Chrome
users will also not able to use existing keys/certificates inside Smart
Cards/USB tokens which was previously also accessible via Java-PKCS#11
implementation..

Best regards,
M Wahaj Khan

CTO | Ascertia Limited | www.ascertia.com | ascertia @ twitter |  Skype:
mwahaj
------------------------------------------------------
Have you tried SigningHub.com? – it's free to try!
Ascertia’s high availability cloud service for document workflow and
digital signature approval

-----Original Message-----
From: charles.engelke@gmail.com [mailto:charles.engelke@gmail.com] On
Behalf Of Charles Engelke
Sent: Thursday, February 26, 2015 2:42 AM
To: public-webcrypto@w3.org
Subject: Suggestions for Web Crypto WG next steps

I came to this group after it completed its draft, so I may not be
addressing this to the right place. Please let me know if that's the case.

Info Tech develops applications for many platforms including the web
browser. We have products and services that use public key encryption
and signing. Right now, we have Windows-only clients and an IE-only
browser plug-in for those functions. We want to move to pure
browser-based clients without plug-ins, and the Web Cryptography API is
allowing us to do so. We thank the WG for that; it's a game changer for us.

But we still want more, and think that other web client application
developers are likely to also want some of the same things. Here are
five suggested areas that we would like to see the WG consider. There
may be issues with them that we don't see, but hope that the general
ideas here can get consideration.

1 - User-controlled export and import of non-extractable private keys.

We'd prefer that private keys used in the browser not be extractable so
that there is no chance of them being disclosed. However, our users' key
pairs are their digital IDs for our services, and they have to register
their public keys along with proof of their identity with us. It is
important that they be able to back up their key pairs and even move
them to other devices. Right now that requires the keys to be extractable.

We would like to see some way a user could export and import keys from
the browser outside the control or awareness of code running in web pages.

2 - Use of platform keys.

One user may use the same key pair with one of our Web Crypto based
applications one day, and with a native Windows one the next. We would
like a web application to be able to request access to keys in a
platform key store such as the Windows certificate store. Any such
request should require independent approval by the user, and should
provide access to cryptographic operations but not the raw keys themselves.

Platforms can have many key stores on them. At a minimum, we recommend
providing access to the key store the browser uses for TLS operations.

3 - Support of deprecated algorithms.

RSAES-PKCS1-v1_5 was removed from the draft last summer because it
should not be used going forward. It seems possible that other
algorithms in the CR might be removed for similar reasons some day.
But users might have old material encrypted or signed with those
algorithms that they want to use.

We propose that, whenever an algorithm is deprecated in the future some
operations continue to be supported for working with legacy data.
For instance, key import, decryption, and signature verification might
still be possible, but key generation, export, encryption, and signing
would not be.

It would also be useful for older, once heavily used algorithms such as
Triple-DES to be supported in a deprecated mode.

4 - Discovery of supported algorithms.

There are no required algorithms or operations for a user agent
supporting web crypto, so applications working with data from other user
agents or applications might work. Application developers would benefit
from a requirement that user agents support a common set of algorithms
and operations. And if some algorithms/operations remain optional, a
better way to discover them while an application is running is desirable.

The only current way to discover whether a user agent supports a
particular algorithm and operation is to try it and see if causes an
error. An API allowing discovery of supported algorithms and operations,
or at least checking them quickly without having to try the operation,
is requested.

5 - Higher-level cryptographic operation support.

Applications using public key cryptography often want to use X.509
certificates and support specific formats such as cryptographic message
syntax and PKCS12 import and export. It is possible to build this
functionality in JavaScript on top of the current API, and some
libraries already exist. But why not provide it as an external API, just
as Web Crypto is? ASN.1 operations are notoriously difficult and likely
to have subtle problems, so why not expose those capabilities from
existing platform-native implementations for use within the browser?


That's our current wish list for web crypto. I hope at least some of
these items are of interest to others participating in the WG.

Thanks,

Charlie
--
Charles Engelke, Chief Technology Officer Info Tech, Inc.
Phone: +1 (352) 381-4400

Received on Wednesday, 11 March 2015 11:02:29 UTC