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, 25 February 2015 21:42:30 UTC