On Sat, 2006-04-08 at 11:20 +0200, Jean-Marc Desperrier wrote: > Your use case is quite unorthodox, and is at risk of being criticized as > such. [...] > So, it seems quite contradictory to hope to get non-repudiation if you > don't care who the user is.
This may well be the case; my model is intended to support agents who aren't necessarily backed by a person (eg, autonomous financial trading agent). All I want to assure is that decisions made by an particular entity to receive money are correlated with the decisions made to disburse it; decisions attested to by cryptographic signatures. But, as you say, the details of this are entirely secondary to the underlying issue. > 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. Should I take it upon myself to raise this in bugzilla? I'm not entirely clear on what the right solution is or even what constraints to describe; crypto.signText at some point calls a very generic CERT_VerifyCertificate, which will fail under the described conditions (no chain back to a root). I presume a good many other certificate operations take the same path, some of which presumably mandate the current behaviour. Which identities should crypto.signText be able to use? (a) Those for which a CA certificate has been loaded but not trusted? (b) Any client certificate, regardless of whether or not the signing CA is known? (c) Something more exotic, such as (a) above except where the call to crypto.signText supplies an unknown CA's DN in the ancillary arguments, in which case any certificates signed by that particular CA are also (or perhaps exclusively) permitted? > Meanwhile what you should be able to do is to mark the CA only as > trusted for email which limits the risks. Thanks for confirming that. m. _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
