Anders Rundgren wrote:
> Quoting Bob Relyea :
The assumption in NSS in the past has been that certUsageEmailSigner
implied non-repudiation, while certUsageSSLClientAuth did not.
I believe this is perfectly OK. It was just the name that caught my attention.
It sounds like it looks for other things than just the non-rep stuff.
I don't know where Bob's message appeared originally. It's not on the
newsserver, on google or my mail (might be the fault of the strong
filtering on alussinan.org).
The trouble is that certUsageEmailSigner in it's current implementation
does indeed look for other things than non-repudiation. It checks that
the certificate is valid to sign mail, ie if it has an Extended key
usage it must include id-kp-emailProtection and the presence or not of
an email address interferes also. So some certificate that are perfectly
valid to sign data do not get certUsageEmailSigner
Also it accepts ordinary signature certificates as well as NR one.
That being said, NSS does not currently filter either of those based on
the non-repudiation bit (IIRC).
There's an entry in bugzilla about that sort of things. But maybe it's
instead to filter out NR cert when requiring an authentication
certificate so that people don't get both more pop-up and the risk of
making the wrong choice when logging in.
Also, there is a growing suspicion that
email should be signed with a 'auth' certificate, since it typically
means 'I sent this', not 'I agree to this'.
I myself think there is three levels :
- true authentification : id-kp-clientAuth
- lightweight signature : the one that you should be able to use on all
your email
- non-repudiable signature : the one for important documents
But that maybe the simplification of using the same cert for the first
two is alright.
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
