Mikolaj Habryn wrote:
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.
Your use case is quite unorthodox, and is at risk of being criticized as
such.
See, you say the above but OTOH you also say :
pushing the private key at the
server right at the start rather throws the whole non-repudiability
thing in doubt :)
So, it seems quite contradictory to hope to get non-repudiation if you
don't care who the user is. I can tell you at least the european
regulation sets as a mandatory step for NR (more precisely for
burden-of-proof reversal) that the certificate used has been issued
under very strict conditions, so that the user can no more deny it's his
certificate (the underlying point for certificates agnostics is to prove
it's his private key) that he can deny having signed.
A private key can not have more value than the process used to issue it.
(consistant use of a given private key can progressively give it value,
but it's something that hardly enters the legalese world)
But let's get back to your basic problem :
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?
In fact I agree that it's not the most common but a valid case to be
able to use a certificate to sign or authentifiate yourself even if you
don't want to mark this CA as trusted for any usage. So this is a bug.
Meanwhile what you should be able to do is to mark the CA only as
trusted for email which limits the risks.
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
