I have to deal with certificates issued by the Swiss post office on USB tokens. There deliver two certificates on the same token. In their intended usage fields, one has \"n
Interesting question, and your thoughts match my own.
I've found a reference at IBM here about key usage, but I still can't really get my head around the distinction.
The best that I can phrase my understanding having read the article is that a non-repudiation usage means "I really meant to sign this, and I really understand the implications of signing this."
Sorry this isn't a complete answer, but I hope it helps.
EDIT 4th April 2014
I just got given more points again. The answer from @Calrion is much better, so send any +1s that way.
This page gives somewhat clear descriptions of all the key usages:
https://www.ibm.com/support/knowledgecenter/en/SSKTMJ_9.0.1/admin/conf_keyusageextensionsandextendedkeyusage_r.html.
I realise this question is a bit old, but I think I can shed some much-needed light on the question.
The non-repudiation value in the keyUsage attribute relates to the whole certificate, not any purpose in particular. The presence of the non-repudiation flag indicates that the private key has sufficient protections in place that the entity named in the certificate cannot later repudiate—deny—actions they take with the certificate. The presence of the flag doesn't prevent repudiation, rather it indicates that repudiation isn't likely to survive reasonable scrutiny.
So in this specific case, the CA is giving the user the option of a certificate that does or does not include the non-repudiation element. If you want to assert to those verifying the signature that you can't easily deny it was you who signed it (the USB token is the key enabler here), use the non-repudiation certificate. Otherwise, use the certificate marked for digital signatures. (Depending on the other attributes in the certificate, you may or may not be able to sign documents with either or both certificates.)
See Wikipedia: http://en.wikipedia.org/wiki/Non-repudiation
See also the relevant RFC: http://www.faqs.org/rfcs/rfc3280.html (section 4.2.1.3)
I talk to the guy who implemented it and, apparently, they intended the "non-repudiation" cert for /really/ signing documents and the "digital signature" one to be used for authentication.
"digital signature" should be used for authentication (it was you, who signed this), while "non repudiation" means that you know what you was signed.
If you use your private certificate for authentication (against some server) the authentication works following way: During establishing the connection your browser (or other SW) signed some random data provided by server to prove that it was you on the other side. But the key point is that you have no control which data you are signing. Thus the server can you send instead of random data send "I, Petr Novonty, give all my money to James Clark."
To avoid this, key used for signing some documents should have "non repudiation" and not "digital signature" bits set.
"digital signature" means that you can garantee the origin of the document or the id of the user; this is AUTHENTICATION.
"non repudiation" means that the document is approved, this is content commitment also called ELECTRONIC SIGNATURE (not digital signature).
Hope this helps cause ones always ask this question even in 2013...
Franck.