I've been playing with crypto.signText for a couple of weeks in the
hopes of using it to build web front-ends for XML-Signature
applications.

At this stage, technically, it all works fine, aside from one annoying
quibble, which is that mozilla wants a certificate to use as the signing
identity for crypto.signText. This isn't in itself too much of a
problem, but crypto.signText then 'error:internalError's unless the CA's
certificate has also been loaded and trusted.

Is this intentional? It's slightly inconvenient for my purposes, since I
absolutely don't care who the user is on the other end and whether or
not they have a client certificate signed by a real CA. I just want a
new user to be able to create a cryptographic ID for crypto.signText on
the spot.

I've knocked up a CA that just signs any CRMF that is handed it
(http://wiki.rcpt.to:8180/pkcs/ca.html) which could potentially be done
entirely behind the scenes, but the need to load and trust the CA
certificate is something of an intrusive drag.

I'm also slightly worried about requiring people to trust a CA that
exists to blindly sign things. Is there a safe combination of trust bits
and/or usage bits imposed by the CA that will allow crypto.signText to
work but prevent any dramatic misbehaviour? I toyed briefly with the
idea of using the key escrow in crypto.generateCRMFRequest to generate
self-signed certificates for users, but pushing the private key at the
server right at the start rather throws the whole non-repudiability
thing in doubt :)

Um. Thoughts?

m.

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

Reply via email to