Re: Smart Card support. Re: Request for feedback: DOMCrypt API proposal

On Thu, Jun 9, 2011 at 12:14 PM, Jarred Nicholls <jarred@sencha.com> wrote:
>> Now, we could just say that the TLS server cert PKI is all we need for
>> establishing trust.  That seems to be an underlying assumption.  Under
>> that assumption there's nothing really wrong with JS crypto APIs.  So
>> I should say that it is this assumption that I take issue with; I plan
>> on expanding on this soon.
>
> I think we can break this down; we have two problems:
>
> Performing cryptographic functions, application driven
> Performing trusted key resolution/exchange for the subset of cryptographic
> functions that require them.

Performing keyed cryptographic operations (as opposed to hash
functions) requires keys.  Whence the keys?  And what are their
semantics?  This is where trust comes in.

If I don't trust some script, then it should have access to no keys
other than those it carries, generates, or exchanges.  But if I don't
trust the script, then what is there to be gained from the script
being able to carry, generate, exchange, and use its own keys?  I see
no advantage to be had from that.

> Application driven - server exchanges with client over secure channel and
> typical authentication system, application manages the key.

Aha!  You're presuming that you have a secure channel.  Let's say you
do have one.  Now what?  Why do any crypto in the script?  To avoid
sending passwords to the server??  But the script came from the
server, so there's no way for the browser nor user to know what the
script is doing with any passwords -- might as well just send them in
the clear over the secure channel (so not actually in the clear over
IP).  What else?  The only way to gain anything here is to let the
script _use_ but not _get_ at locally-stored keys (i.e., on a
smartcard or softtoken).

> User driven - user my provide a key via smart card, choosing a key from
> their OS key ring, selecting a private key file, whatever.

Right.  But then I, as a user, had better know whether the given
script (page, really) is trusted (by my user agent, and, by extension,
me).  And then we get right back into trust issues.

> I am focusing on #1, and you are focusing on #2.  They are not the same
> problem in my eyes.  #2.1 and #2.2 are also not the same problem.  However,
> both #2.1 and #2.2 would occur first and then use #1 for the subset of
> crypto functions that are key based; once a key is received, the application
> can go to town.  How that key is received and whether it can be trusted by
> the user is a problem that needs to be solved, but is not a prerequisite to
> these simple/dumb APIs.

I disagree.  For any keyed crypto operations you have to solve the
problem of where the keys come from, where they are stored, who has
access to them, and what you get out of having such keys (and keyed
crypto ops).

Nico
--

Received on Thursday, 9 June 2011 17:58:37 UTC