Web Crypto API(s) and what Mozilla wants / needs

[David Dahl]

Hello dev-tech-crypto:

I want to solicit more opinions, criticism and feedback around the W3C Web Crypto API. Based on this feedback, I want to try and gauge what kind of implementation resources we might put on this API.

* Charter: http://www.w3.org/2011/11/webcryptography-charter.html
* (lower-level API) https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html
* (higher-level API) https://dvcs.w3.org/hg/webcrypto-highlevel/raw-file/tip/Overview.html
* Use Cases: https://dvcs.w3.org/hg/webcrypto-usecases/raw-file/tip/Overview.html

The Working Group charter specifically states that the WG is working on a high-level API that web developers will be able to approach somewhat easily. The low-level public working draft we have is not that API, rather it is a quite a bit lower-level than what I imagined when pushing DOMCrypt ( https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest ) - which was the initial strawman for the W3C Web Crypto WG.

While this API is designed to be rather open-ended and allow inter-interoperability with existing systems and protocols, I fear we are handing web developers a 'footgun'. Naturally, a JS library will evolve that wraps this API, making it much easier to use - won't having a simpler API built into the browser be safer? (The jury seems split here)

DOMCrypt was originally designed to try and 'simplify' a crypto API for the DOM, allowing relative novices to get useful (non-backward-compatible) functionality. I think having a low-level API is going to be great, but, based on a lot of the feedback on our FPWD, I wanted to try and draft a high-level API that did only encryptAndSign/decryptAndVerify (public key) and seal/open (symmetric key).

The main issue is: What does Mozilla actually need here? What is Mozilla's official policy or thinking on a crypto API for the DOM?

The working group is also very interested to know what a potential timeline is for Mozilla to implement.

Regards,

David

[Anders Rundgren]

Hi David,

IMO the Web Crypto API is on the right level.

There are tons of people out there that are writing wrappers and
that covers the need you mention.

What Mozilla really need is a new PKI client, the current is useless,
particularly for B2G (since PCs seem to be a lost case due to MSFT):

http://webpki.org/papers/PKI/certenroll-features.pdf

Mozilla's <keygen> meets a *single* of these possible requirements
which forces most serious parties to "roll-their-own".

Since you asked about Web Crypto, my question remains: how does
Web Crypto WG intend to deal with keys in NSS, CryptoAPI, "KeyChain"?

br
ar

[helpcrypto helpcrypto]

Hi David.

First: Thank you (all) for your hard work on this.
Second: Sorry for any mistake, typo or pocahontas speak.

IMHO we NEED this, and Mozilla NEED it also.

In our case, we are currently using a Java applet to make digital
signature of documents in many formats (XMLDsig, XAdES, PAdES...)
using client certificates (RSA X509) stored on NSS/smartcard/CSP.
We are not using the Mozilla signText, cause its HORRIBLY user
unfriendly (showing unreadable text doesnt truly accomplish
contentCommitment), cant be used to sign "a bunch of documents", its
different from MSCAPI...among other things.

Of course, as your API only handles keys (and how to get them from an
smartcard is out of scope), IMHO theres a HUGE gap between your API
and the real world. There are, already, a lot of JS libraries to do
cryptographic operations, but is the lack of PKCS#11/NSS support which
make them useless.
In recent versions of the draft, you have added "19. Key Discovery",
and thats is, IMHO, the key of success.

I think you are going in the correct, but if you dont work on "how to
get the keys from the smartcard" or "how to sign 3 documents without
requiring PIN 3 times (if smartcard allow it)" [I already suggested
signInit-Add-Final methods based on PKCS#11 sign functions], we will
still need Java Applets.
And that sux.

Just my 0.02

> What Mozilla really need is a new PKI client, the current is useless,
> particularly for B2G (since PCs seem to be a lost case due to MSFT):

Altought im not yet convinced that Anders proposal for a new PKI
system its the final solution, probably because i lack needed skills,
i TOTALLY agree with him: i dont like the way to request a certificate
using Mozilla. Either genkey (where i cant control if they are
generated on my smartcard or nss, or the keysize they have...unless
messing with DOM :P)

> Since you asked about Web Crypto, my question remains: how does
> Web Crypto WG intend to deal with keys in NSS, CryptoAPI, "KeyChain"?

Again, IMHO, theres should be a way to request "in which smartcard"
you want to generate/use the key, using pkcs#11 module name, for
example.

[Gervase Markham]

On 13/02/13 20:55, David Dahl wrote:
> The main issue is: What does Mozilla actually need here? What is
> Mozilla's official policy or thinking on a crypto API for the DOM?

As you are the Mozillian with most experience in this area, I'd say that
insofar as we will ever have an official policy, it's likely to be "what
you think" (after taking the input of others, as you are doing). Please
feel empowered :-)

Gerv

[David Dahl]

I do understand the frustration you must feel in trying to get browsers to work closely with your national ID/Cert system. There are many such systems, and trying to create an API that works with your specific requirements, hardware and regulations is very difficult. The WG notes this by placing such efforts in the WG's "secondary features". This is a shame, but it is also a bit of realism as getting caught up in multiple varying national schemes may have stunted progress on a more generic API, which I feel is a first priority.

I wish there was more homogeneity in these systems.

-david

[David Dahl]

----- Original Message -----
> From: "Gervase Markham" <ge...@mozilla.org>
> To: mozilla-dev...@lists.mozilla.org
> Cc: "Eric Rescorla" <e...@mozilla.com>, "Brian Smith" <bsm...@mozilla.com>, "Brendan Eich" <bre...@mozilla.com>, "Ben
> Adida" <bena...@mozilla.com>, "Brian Warner" <war...@mozilla.com>
> Sent: Thursday, February 14, 2013 5:22:41 AM
> Subject: Re: Web Crypto API(s) and what Mozilla wants / needs
>

Ah, thanks! I am however, not a 'crypto expert' and would like the actual experts to weigh in and set the 'policy' (for lack of a better word.) At this point in the game, it would seem that FirefoxOS, with it's enhanced security model, would benefit greatly from APIs like this. I am hoping that will help in garnering the resources to implement and/or develop an engineering schedule for this.

-david

>
> Gerv
> --
> dev-tech-crypto mailing list
> dev-tec...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>

[David Dahl]

[Robert Relyea]

Well, I am quite pleased with the approach of providing a limited
controllable set of primitives that are easy to use. The encrypt/sign -
decrypt/verify using PKI completely sounds like the right first
primitive to supply, along with seal/unseal. Key management/key exchange
is the hardest part to get right in crypto. Both of these provide the
simplest model for managing these things.

I'm sure there are lots of applications where these primitives are
insufficient, but enabling a stable set that is easy for the non-crypto
person to get right definately sounds like the right way to move
forward. (Both of these also has the advantage of allowing you to define
API's where algorithm selection can be automatic, meaning the users
automatically get new algorithm support without having to change the
javascript application.


bob

[Ryan Sleevi]

Agreed on key management/key exchange. Note that the current proposal
intentionally largely tries to avoid these matters, for that reason.
Instead, it operates on the presumption that the user has a Key object,
and the question is what operations can be performed with it.

>
> I'm sure there are lots of applications where these primitives are
> insufficient, but enabling a stable set that is easy for the non-crypto
> person to get right definately sounds like the right way to move
> forward. (Both of these also has the advantage of allowing you to define
> API's where algorithm selection can be automatic, meaning the users
> automatically get new algorithm support without having to change the
> javascript application.

Bob,

As you mentioned, there are lots of applications where these primitives
are insufficient. Certainly, NSS would not be in usable today for Firefox
or Chromium if it adopted only the high-level approach being proposed (and
as reflected in APIs like KeyCzar and NaCL). Likewise, NSS's highest-level
APIs (like S/MIME) go largely unmaintained/unused, while the low-level
crypto is used in a variety of projects (as shown at the sheer number of
packages converted at
http://fedoraproject.org/wiki/FedoraCryptoConsolidation ).

Do you know of any applications where they *would* be sufficient? Do you
anticipate non-crypto people to be able to use 'crypto', even high-level,
for the development of an overall secure system? I'm aware of the
arguments made in http://cr.yp.to/highspeed/coolnacl-20120725.pdf , and I
certainly support a high-level API, but I don't think you avoid any of the
thorny issues (algorithm negotiation, wire format, etc), and I'm not sure
that the high-level API makes the overall *application* any more or less
secure than a low-level API using recognized primitives.

I guess it's my way of suggesting I'm more concerned about the places
where "these primitives are insufficient", and I'm less convinced of the
idea that it any more easier "for the non-crypto person to get right".
Given your long-standing role in NSS, I'm curious your thoughts on the
types of applications that would be able to actually (and successfully,
and securely) use such an API.

Cheers,
Ryan

[John Dennis]

Sorry to butt in on a question directed to Bob, but ...

Here's one data point. I constantly hear the complaint from developers
that NSS is too low level and using it is too hard. They wonder why
there can't be a higher level API that insulates them from many of the
quirky details they find somewhat incomprehensible leaving them with
doubts about the correctness of what they've done and dismayed at the
time it took to accomplish it.

So yes, I think higher level API's would be welcome. I also think it
would be welcome if the high level API interfaces permitted swapping out
the low level crypto library on which they are based. Why? It's not
unusual for someone with a problem to be asked, can you use X, Y, or Z
instead and tell me if you still have the issue. That's a non-starter
for many applications unless they had the foresight to implement
"pluggable crypto", and I'm only aware of a handful of those, usually
they've hitched their horse to one implementation.


--
John Dennis <jde...@redhat.com>

Looking to carve out IT costs?
www.redhat.com/carveoutcosts/

[Ryan Sleevi]

John,

Surely you're not suggesting that arbitrary web applications be able to
use JavaScript to swap out the crypto library used by the browser?

This is purely in the context of a Javascript API intended for both web
applications AND extensions (or, in the case of B2G, B2G Apps). So there's
a wide spectrum of possible applications that may be developed or wish to
be developed.

For example, would a B2G SSH be possible? ConnectBot is quite popular on
Android - after all, AIUI, the NSS Android builds themselves rely on
having an SSH app installed on the phone (Kai, is that a correct
understanding?)

Were you perhaps talking about a new C API for high-level crypto, that
interops with multiple 'lower' level APIs (if so, what APIs?). Arguably,
NSS is itself a 'pluggable' crypto - everything in pk11wrap and higher is
implemented in terms of PKCS#11 - that is, not directly talking to
softoken, but speaking to generic PKCS#11 modules and slots, which are a
standard abstraction for crypto modules/libraries.

[John Dennis]

On 02/14/2013 03:19 PM, Ryan Sleevi wrote:
> On Thu, February 14, 2013 11:55 am, John Dennis wrote:


> Surely you're not suggesting that arbitrary web applications be able to
> use JavaScript to swap out the crypto library used by the browser?

Absolutely not from JavaScript. But as a browser config sure.

> This is purely in the context of a Javascript API intended for both web
> applications AND extensions (or, in the case of B2G, B2G Apps). So there's
> a wide spectrum of possible applications that may be developed or wish to
> be developed.
>
> For example, would a B2G SSH be possible? ConnectBot is quite popular on
> Android - after all, AIUI, the NSS Android builds themselves rely on
> having an SSH app installed on the phone (Kai, is that a correct
> understanding?)
>
> Were you perhaps talking about a new C API for high-level crypto, that
> interops with multiple 'lower' level APIs

Yes that's where my thoughts were going. If high level Javascript as
well as C/C++/Java/Python/Ruby etc. API's followed the same models, used
the same terminology, names, and fundamental objects I think it would be
a huge win.

It seems to me the current state of affairs is there is wealth of
incompatible poorly written crypto API's across a range of languages and
environments. Good API design is an art. Having a crypto guru write a
crypto API for the masses is akin to asking a kernel developer to
develop a friendly user interface, it's possible but not likely.

I think where I was going is if this effort could yield a simple, easy
to use, easy to comprehend, easy to be secure API that serves 90% of the
common use cases then I think it would have accomplished something we
haven't achieved yet, and if so it can be a model to converge on. It
would be something the whole software ecosystem would appreciate. I'd
like to see a lot more focus on API design driven by usability
requirements instead of driven by the underlying implementation.

A lot of effort has to go into developing abstractions while rigorously
applying the simplicity test. I'm afraid committees have a poor track
record in this regard FWIW. :-(

> (if so, what APIs?). Arguably,
> NSS is itself a 'pluggable' crypto - everything in pk11wrap and higher is
> implemented in terms of PKCS#11 - that is, not directly talking to
> softoken, but speaking to generic PKCS#11 modules and slots, which are a
> standard abstraction for crypto modules/libraries.

Well, I think it might be a bit a stretch to call NSS pluggable, but I
see where you're coming from. There is still a fair amount of ground not
covered by PKCS11. I think one might be hard pressed to have a rich
crypto environment while restricting yourself to only what's available
via PKCS11, but your point is taken. Also PKCS11 is a bit long in the
tooth by contemporary standards, but that's another topic.

[Martin Paljak]

Hello,

On Thu, Feb 14, 2013 at 5:48 PM, David Dahl <dd...@mozilla.com> wrote:
> I do understand the frustration you must feel in trying to get browsers to work closely with your national ID/Cert system. There are many such systems, and trying to create an API that works with your specific requirements, hardware and regulations is very difficult. The WG notes this by placing such efforts in the WG's "secondary features". This is a shame, but it is also a bit of realism as getting caught up in multiple varying national schemes may have stunted progress on a more generic API, which I feel is a first priority.

Given that I'm a citizen of a country that has a national ID system
and I've also had to/tried to make browsers (including Firefox) work
closely with it, I'd like to ask this controversial question:

Maybe creating a "PKCS#11 for javascript" will not fix anything,
except create a new fantastic attack vector and source for mitm/timing
attacks? Maybe analyzing the higher level implementations would
actually reveal requirements (legal and operational), when catered for
would actually benefit a fair amount of users? Given that usecases of
a citizen don't differ that much from average corporate users, the
work would most probably be useful to two important groups: corporate
users and "average home users".

The fact that in browser world only Firefox depends on PKCS#11 and
thus lags behind in features and interoperability on platforms where
more useful and serious API-s are present is a sign that *maybe*
PKCS#11 really is just a low level plumbing API for scenarios where
plumbing matters (maybe HSMs, but deficiencies and proprietary
solutions are not su uncommon there as well).

In fact, I think that the most ambiguous standards/specifications I've
worked with are PKCS#11 (where most "interesting" things are left out
of the scope) and ISO7816 and friends, where most is optional and
choices to choose from are plenty.

Users choose a working tap over interoperable plumbing elements. Maybe
trying to design a tap instead of plumbing joints would be a better
idea. I think that plumbers would also like it.

[Anders Rundgren]

On 2013-02-15 06:38, Martin Paljak wrote:
> Hello,
>
> On Thu, Feb 14, 2013 at 5:48 PM, David Dahl <dd...@mozilla.com> wrote:
>> I do understand the frustration you must feel in trying to get browsers
> to work closely with your national ID/Cert system. There are many such
> systems, and trying to create an API that works with your specific
> requirements, hardware and regulations is very difficult. The WG notes
> this by placing such efforts in the WG's "secondary features".
> This is a shame, but it is also a bit of realism as getting caught up
> in multiple varying national schemes may have stunted progress on a more
> generic API, which I feel is a first priority.
>
>
> Given that I'm a citizen of a country that has a national ID system
> and I've also had to/tried to make browsers (including Firefox) work
> closely with it, I'd like to ask this controversial question:
>
> Maybe creating a "PKCS#11 for javascript" will not fix anything,
> except create a new fantastic attack vector and source for mitm/timing
> attacks? Maybe analyzing the higher level implementations would
> actually reveal requirements (legal and operational), when catered for
> would actually benefit a fair amount of users? Given that usecases of
> a citizen don't differ that much from average corporate users, the
> work would most probably be useful to two important groups: corporate
> users and "average home users".

Hi Martin,

As far as I can tell, the current Web Crypto API doesn't address national
eID-cards at all. IMO, the most workable (security + privacy + usability)
solution for such support requires dropping arcane stuff like PKCS #11 and NSS and
turning to more current security-architectures, like the one powering the Google Wallet,
where the security-resource itself declares which applications are allowed to access it.

By doing that you don't get separate tracks for "apps" and the web and you will also
be able to provision and manage security-resources through unified mechanisms.

This obviously requires signed application-code and that the "crypto API" runs as
a part of the OS or in a specific TEE (Trusted Execution Environment).

Anders

[helpcrypto helpcrypto]

>>> I do understand the frustration you must feel in trying to get browsers
>> to work closely with your national ID/Cert system. There are many such
>> systems, and trying to create an API that works with your specific
>> requirements, hardware and regulations is very difficult. The WG notes
>> this by placing such efforts in the WG's "secondary features".
>> This is a shame, but it is also a bit of realism as getting caught up
>> in multiple varying national schemes may have stunted progress on a more
>> generic API, which I feel is a first priority.

As usual, sorry for my lack of english, and thank you for your time and work.

In one hand, I probably lost something in the translation of your
answer, Martin's and Anders's, and I dont have your knowledge on this
field. By far.
In the other hand, Im one of your potential "customers" (I dont see
users invoking sign operations, but crypto/egovernment developers
adding "sign" button on web forms), and im expressing you -designer-
what i need/pray for.

In our case, im not talking about having issues working with "national
ID/Cert system", but doing document signatures, which is done
worldwide.

IMHO, once we have a pkcs#11 interface to handle any smartcard, even
installed cert using NSS softoken, and maybe a wrapper to mscapi...the
only thing left is to use those certs stored "somewhere" with your
javascript API.

In other words:
I like your "simple" approach, but i dont need it/cant use it, if you
dont allow me to use installed certs/smartcard certs.
If you make this possible, EVERY cryptographic web developer I know
which does digital signature using a java applet, will move to this
library, completely happy.

BTW: what about the init-add-final for multiple signing without
requesting password many times?


Of course we also have issues related to keygen and getting
certificates from CA, but this is another story which, in my opinion,
will need something like Anders proposal, as you mention.

But i want to repeat myself: we are talking about two different problems.


...we could also talk about bribery...whats your price? :P
Happy weekend!

[Anders Rundgren]

On 2013-02-15 09:46, helpcrypto helpcrypto wrote:

<snip>

> IMHO, once we have a pkcs#11 interface to handle any smartcard, even
> installed cert using NSS softoken, and maybe a wrapper to mscapi...the
> only thing left is to use those certs stored "somewhere" with your
> javascript API.

The problem with this approach is that you expose keys to arbitrary javascript
code which is rather different to for example TLS-client-certificate
authentication which only exposes a high-level mechanism as well as a
[reasonably] secure credential filtering scheme and user GUI.

I.e. we need something similar to your current signed java applets in
order to enable web-based javacript access to keys in NSS et al.

I have proposed using the model used in Google Wallet which is signed
code with a twist: It is not the platform (or you) that trusts the
code, it is the security resource.

Traditional signed code is IMO rather lame since anybody can buy
a valid code-sign certificate. I.e. a code signature from someone
you never heard about is doesn't add much to the table.

Anders

[helpcrypto helpcrypto]

> The problem with this approach is that you expose keys to arbitrary javascript
> code which is rather different to for example TLS-client-certificate
> authentication which only exposes a high-level mechanism as well as a
> [reasonably] secure credential filtering scheme and user GUI.

clear as water.

Shouldnt we be able to expose "key handles" rather than keys?
ie: javascript invoke getKeyFromPKCS11("modulename") and "#1" is
returned, but can be used.

> Traditional signed code is IMO rather lame since anybody can buy
> a valid code-sign certificate. I.e. a code signature from someone
> you never heard about is doesn't add much to the table.

Agree

[Martin Paljak]

On Fri, Feb 15, 2013 at 12:32 PM, helpcrypto helpcrypto
<helpc...@gmail.com> wrote:
>> The problem with this approach is that you expose keys to arbitrary javascript
>> code which is rather different to for example TLS-client-certificate
>> authentication which only exposes a high-level mechanism as well as a
>> [reasonably] secure credential filtering scheme and user GUI.
>
> clear as water.
>
> Shouldnt we be able to expose "key handles" rather than keys?
> ie: javascript invoke getKeyFromPKCS11("modulename") and "#1" is
> returned, but can be used.

I think we all mean "key handles" instead of "plaintext key material"
but the problem is the same - keys get exposed "naked" and can be
(ab)used for whatever.

Martin

[helpcrypto helpcrypto]

> I think we all mean "key handles" instead of "plaintext key material"
> but the problem is the same - keys get exposed "naked" and can be
> (ab)used for whatever.

I mean, apart from malicious sign operations, i dont see any risk on
javascript "seeing" a key handle. Is there any?

If the only risk are malicious sign request...I agree something like
"you are going to sign..." and requesting a PIN is not enough to
prevent users clicking without read, but isnt crypt.signText actually
doing the same?

[Anders Rundgren]

On 2013-02-15 11:32, helpcrypto helpcrypto wrote:
>> The problem with this approach is that you expose keys to arbitrary javascript
>> code which is rather different to for example TLS-client-certificate
>> authentication which only exposes a high-level mechanism as well as a
>> [reasonably] secure credential filtering scheme and user GUI.
>
> clear as water.
>
> Shouldnt we be able to expose "key handles" rather than keys?

Yes, that's was the intention.

> ie: javascript invoke getKeyFromPKCS11("modulename") and "#1" is
> returned, but can be used.

How do you envision that this access should be controlled?
Here imagine that you have dozens of keys, not just a single key in a smart card.

A difference to keys compared to for example "your location" (which is
exclusively your resource) is that keys in most cases are given to users
by external providers. The providers do not want their keys to be misused,
particularly not by users who accidentally made the wrong trust assertion.

A scheme that doesn't take this in account IMO has little chance of getting
market acceptance.

In my professional life I deal with PKIs for EAC (Extended Access Control)
which is used in e-passports for selective access to biometric information.
Using EAC it is the *passport* that grants access based on credentials provided
by the inspection systems so what I'm proposing is by no means a "novelty";
it just haven't reached the web. Yet.

Anders

[helpcrypto helpcrypto]

>> ie: javascript invoke getKeyFromPKCS11("modulename") and "#1" is
>> returned, but can be used.
>
> How do you envision that this access should be controlled?
> Here imagine that you have dozens of keys, not just a single key in a smart card.

The same way as SSL client authentication: with a dialog letting the
user select between the certs stored on that pkcs#11.

> A difference to keys compared to for example "your location" (which is
> exclusively your resource) is that keys in most cases are given to users
> by external providers. The providers do not want their keys to be misused,
> particularly not by users who accidentally made the wrong trust assertion.

IIUC, you mean "keys from A certificate authority intended to be used
in domain X shouldnt be (ab)used by domain Y"?
Is that what you mean?

> A scheme that doesn't take this in account IMO has little chance of getting
> market acceptance.

Maybe i didnt explained myselft properly. Im not suggesting a "new
scheme", just making this JS crypto library "backwards compatible"
with the system currently using.

> In my professional life I deal with PKIs for EAC (Extended Access Control)
> which is used in e-passports for selective access to biometric information.
> Using EAC it is the *passport* that grants access based on credentials provided
> by the inspection systems so what I'm proposing is by no means a "novelty";
> it just haven't reached the web. Yet.

As with other issues, i probably lack of needed skills and knowledge
to discuss these things. Im just a developer which uses Java applets
cause theres no better alternative.

[helpcrypto helpcrypto]

So, to sum up:

Will it be possible, using Web-Crypto API, to sign using a Pkcs#11
key/cert? What about MSCAPI key/cert?

Will it be possible, using Web-Crypto API, to sign in batch-mode?

Thanks for answers!

[Anders Rundgren]

On 2013-02-21 09:22, helpcrypto helpcrypto wrote:
> So, to sum up:
>
> Will it be possible, using Web-Crypto API, to sign using a Pkcs#11
> key/cert? What about MSCAPI key/cert?

No.

>
> Will it be possible, using Web-Crypto API, to sign in batch-mode?

Since your requirement was associated with giving a PIN once and
PINs are not a part of the WebCrypto API the question doesn't really
apply.

Anders


>
> Thanks for answers!
>

[helpcrypto helpcrypto]

BTW, what is this?
http://html5.creation.net/webcrypto-api/

[Mountie Lee]

this was initial draft from Channy of Mozilla KR community.

as I know, Mozilla DOMCrypt moved to WebCrypto project.

and narrowing focus to primitive features first.

> --
> dev-tech-crypto mailing list
> dev-tec...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>

--
Mountie Lee

PayGate
CTO, CISSP
Tel : +82 2 2140 2700
E-Mail : mou...@paygate.net

=======================================
PayGate Inc.
THE STANDARD FOR ONLINE PAYMENT
for Korea, Japan, China, and the World

[Anders Rundgren]

On 2013-02-21 12:28, helpcrypto helpcrypto wrote:
> BTW, what is this?
> http://html5.creation.net/webcrypto-api/
>

These are the s.c. "Korean Use-cases" which have largely been ignored by the Web Crypto WG.

Anders

[Anders Rundgren]

>
> Will it be possible, using Web-Crypto API, to sign in batch-mode?
>

Like this, I presume:
http://www.secrypt.de/en/products/digiseal-office-pro

I believe Germany is about the only country using such schemes.
IMO it is based on an altogether weird interpretation and use of
the EU signature directive which forces German companies to sign
e-invoices as individuals, rather than by a server-hosted "company stamp".

This makes the use of batch signatures a necessity for electricity and
telecom bills since these are issued in huge volumes.

Needless to say Germany is way behind the rest of the world in
secure e-invoicing.

Anders

[helpcrypto helpcrypto]

When we have to generate signed copies for a lot of documents (eg:
student course certificates), we use our applet the following way:

- step 1: authenticate and retrieve certificate to use
- setp 2 (n times): sign using selected certificate

Of course, there are risks of signing undesired documents, but thats
another story.
Obviously, our smartcard doesnt have the CKF_ALWAYS_AUTHENTICATE PKCS#11 flag.

We do this A LOT, and this will be great (if possible) through javascript.
Did I say I dont like using Java applets?

[Anders Rundgren]

On 2013-02-21 18:39, helpcrypto helpcrypto wrote:
> When we have to generate signed copies for a lot of documents (eg:
> student course certificates), we use our applet the following way:
>
> - step 1: authenticate and retrieve certificate to use
> - setp 2 (n times): sign using selected certificate
>
> Of course, there are risks of signing undesired documents, but thats
> another story.
> Obviously, our smartcard doesnt have the CKF_ALWAYS_AUTHENTICATE PKCS#11 flag.
>
> We do this A LOT, and this will be great (if possible) through javascript.
> Did I say I dont like using Java applets?

In my opinion this is a perfect application for server-based signatures.
What's needed is an authorization signature where a responsible person
attests that he/she have verified the correctness of the input data
that I guess is presented in web format.

The attestation would be stored in the information system together
with the student information.

The student certificates would presumable be distributed in PDF format
with the educational institution's signature. The attestation is only
of interest for internal processes since the signing individual most
likely is unknown by outsiders. There are also huge problems using
employee certificates outside of the employer border while a legal
entity (organization) certificate actually can be issued by TTPs.

Anyway, the Web Crypto API doesn't address traditional signature applications.
At least, I cannot see that based on the current draft.

Anders

[helpcrypto helpcrypto]

> In my opinion this is a perfect application for server-based signatures.
> What's needed is an authorization signature where a responsible person
> attests that he/she have verified the correctness of the input data
> that I guess is presented in web format.
>
> The attestation would be stored in the information system together
> with the student information.

In our case, we use both server/application and user certificates.
When a student request his "career gradebook", the signature must be
from the entity (organization)
When the teacher send course certificates, must be teachers (personal)
When the director make a public announcement, its also signed by their
own role-certificate (director)
There are also employee certs...

> The student certificates would presumable be distributed in PDF format
> with the educational institution's signature. The attestation is only
> of interest for internal processes since the signing individual most
> likely is unknown by outsiders. There are also huge problems using
> employee certificates outside of the employer border while a legal
> entity (organization) certificate actually can be issued by TTPs.

Usually some documents have only "internal meaning", but some other,
even signed by personal certs (not just institutional seals) can ve
verified externally.
In fact, we use "recognized signatures", which can be verified by
anyone, anywhere.

Even more when using STORK [1] compliance credentials, where national
ID signatures can be verified by other countries. We are starting to
use this when submitting papers.
We also use Certified copies.

> Anyway, the Web Crypto API doesn't address traditional signature applications.
> At least, I cannot see that based on the current draft.

And thats my point.
Im missing both things: smartcards and batch. With them, there will be
an alternative to Java. Without them, ill have to continue using Java.

[1] https://www.eid-stork.eu/