I believe that a requirement that the signer certificate must be trusted (in a
trusted CA
store?) is entirely wrong as it makes the whole scheme non-portable. There are
NO
requirements in FIPS-201 and similar that you must have a CA certs and that
they must be installed from the card in some magical way.
This is indeed a bug.
BTW, is SSL-client-auth also broken? I assume not, otherwise there would have
been quite a number of complaints.
Most signature systems on the market suppport certificate filtering in simikar
ways to
SSL.
Anders Rundgren
----- Original Message -----
From: "Jean-Marc Desperrier" <[EMAIL PROTECTED]>
Newsgroups: mozilla.dev.tech.crypto
To: <dev-tech-crypto@lists.mozilla.org>
Sent: Saturday, April 08, 2006 11:20
Subject: Re: certificate requirements for crypto.signText
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
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
