According to other people, this is just one of many flaws in signText (). Apparently it does not accept the NR bit either.
Essentially the whole filtering thing is upside-down. In an on-line scenario it is the relying party that should specify what kind of clients certs that it will accept. The crude scheme featured in TLS is though not granular enough for this purpose. a. ----- Original Message ----- From: "Mikolaj Habryn" <[EMAIL PROTECTED]> To: "Bob Relyea" <[EMAIL PROTECTED]> Cc: "Anders Rundgren" <[EMAIL PROTECTED]>; "Mozilla Crypto" <dev-tech-crypto@lists.mozilla.org> Sent: Monday, September 11, 2006 08:38 Subject: Re: The Mozilla trust model & FIPS201 On Sun, 2006-09-03 at 17:53 -0700, Bob Relyea wrote: > Of course in the SSL client auth case, you just need to chain to a cert > the server trusts. I have built several demos where the back end Server > is the only one that trust a particular CA which a smart card is issued. > FF quite happily will use the cert from the smart card even though it > doesn't trust the cert itself. It should be easy enough to try for yourself. Sorry, very late reply. The above doesn't work for crypto.signText, which calls CERT_VerifyCert on the certificate it's attempting to sign with, which bombs if the browser lacks a valid trust chain. Comes back with an error:internalError in Javascript. I wound up instructing users to load the CA certificate and mark it as trusted for email. m. _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
