[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: digitalSignature vs. nonRepudiation
I believe the question should be
"what purposes are to be enabled by setting bits 0 and 1 in the
"what is the True Meaning of the words digitalSignature and
The digital signature cryptographic mechanism can be used for many
*purposes*, including signing certs, signing CRLs, signing contracts,
signing email messages, signing various data in ISAKMP, TLS, or other
protocol exchanges, etc.
The digital signature cryptographic mechanism can be used to provide
several *security services*: data integrity, data origin authentication,
entity authentication, and non-repudiation.
All of the bits in the KeyUsage extension, with the possible exception
of NR, refer to purposes, not security services. keyEncipherment,
dataEncipherment, keyAgreement, keyCertSign, crlSign, encryptOnly, and
decryptOnly are purposes for which the key is authorized to be used.
To be consistent, the nonRepudiation bit must refer to certain purposes
for which the NR security service is required (such as signing email),
*not* all invocations of the NR security service itself. For example,
issuing (signing) a certificate involves the NR security service, but
keys issued solely for the purpose of signing certs don't normally have
the nonRepudiation bit set in addition to the keyCertSign bit. The
*usage* of the key is to sign certs, regardless of the fact that the
process of signing a cert also creates data which can be used to refute
any attempted repudiation of the signature by the CA.
Which brings us to bit 0: digitalSignature. X.509 defines this bit
a) digitalSignature: for verifying digital signatures that have
purposes other than those identified in b), f), or g) below;
PKIX defines this bit as follows:
The digitalSignature bit is asserted when the subject public key
is used to verifying [sic] digital signatures that have purposes
other than non-repudiation, certificate signature, and CRL
signature. For example, the digitalSignature bit is asserted
when the public key is used to provide authentication.
>From a practical perspective, it is useful to issue certs for the
purpose of allowing the subject to authenticate (as in a TLS
or IPSEC connection), to attach a signature to a message (as in S/MIME),
to do both, or to do neither. Bits 0 and 1, as defined in X.509 and PKIX,
allow these four possibilities.
If one claims that one cannot do nonrepudiation without integrity and
therefore every certificate with bit 1 set must also have bit 0 set,
then it becomes impossible to specify a keyUsage which is valid for
S/MIME message signing but not valid for TLS authentication. This
is the undesirable outcome of that line of reasoning. An even more
undesirable outcome is that it becomes impossible to designate a key
solely for the purpose of issuing certificates -- that key must also
have the DS and NR bits set. I would prefer that a CA have the option
of restricting one key to just signing certs, and use a different key
> From: "Simonetti David" <email@example.com>
> I am attempting to implement the key usages as defined for the keyUsage
> extension. I am stumbling upon digitalSignature and nonRepudiation.
> I define the key usage digitalSignature as a public key which affords
> the services of authentication and data integrity.
> Of course, nonRepudiation affords the service of non-repudiation.
> My question is, with only nonRepudiation set (and not digitalSignature),
> is it true that my public key can be used only to provide the service of
> non-repudiation, and NOT the services of authentication and data
> integrity? If this is true, I'm curious to know how this is
> I claim that if the nonRepudiation bit is set, that I can use that key
> to implement authentication and data integrity, and also claim
> nonRepudiation of the originator. Since authentication and data
> integrity are services provided under digitalSignature, I believe that
> when nonRepudiation is set, digitalSignature should also be set.
> I'd like to hear agreements or disagreements with my line of reasoning.
> Dave Simonetti