Re: Defining Non-Repudiation

At 01:44 AM 8/22/98 +0200, you wrote:
>I went through a 6 month process in finalizing our certificate policy in
>cooperation with Sweden's best legal experts in this area.
>

Stefan,

Thank you for the response.  It does help clarify the relationships.
Also, your last response to the thread "authentication vs binding sigs"
helped by explaining that these bits indicate an "allowed" activity,
and must be interpreted independently.  It is thus for the application
to decide when a particular combination is inappropriate.

I have just a few comments/questions, below.

>May I very shortly offer some of our basic conclusions:
>
>1) When a CA issues a certificate it will be tied to some defined
>liabilities towards subscribers and relying parties.
>
>2) The CA can state limitations on these liabilities for damages in certain
>situations which may include limitations of liability if the certified key
>was used in conflict with its key usage definitions.

Here, the term "used in conflict with" has two sides.  One side is the use of
the private key in conflict with its certified usage.  This implies that a key
is never certified (by separate certificates/CAs) for conflicting usages.
The other side is application of verification which ignores or contravenes
the specified usage in the certificate.  I wonder if it will often be unclear
which of these two usages was the source of a conflict.

Again, the issue of "one-key, one-cert" seems critical here.  I believe that
some client applications (most browsers?) will generate a key-pair internally
during a certificate subscription operation, thereby giving the CA some
confidence that this is a new (hence unique) key-pair.  Is this a general
rule, or are there applications where the key owner can submit a previously-
generated public key for certification?
  
>3) The CA does not guarantee anything except that it will follow the
>practices and procedures defined by the policy, and specified by its CPS.

I've never personally seen a CPS.  Would I need to hire a lawyer to
explain it to me? ;)

>4) If the CA identifies the key usage "non-repudiation" in a certificate,
>this will only tell the signing entity and the relying party that the CA
>will be bound by its liabilities if the key is used for such service.

I presume that the CPS specifies distinct liabilities for DS, NR, etc.

>5) If a signature is repudiated the involved entities are faced with a
>dispute resolution procedure, according to law and/or their mutual
>agreements, which might take place in court. In this procedure the parties
>will provide evidence for their case. Such evidence may include the
>certificate, certificate policy and the CPS undertaken by the CA as a help
>to establish the evidence value of the signature.
>
>6) If the dispute resolution leads to losses for some entities, due to an
>incorrect issued certificate or other faliure by the CA, the party
>suffering from losses may claim compensation from the CA. In this case the
>CA may be liable for some part of the losses IF the CA has failed to meet
>its obligations. 
>
>So non-repudiation is nothing definite and it includes several aspects and
>independent relations. The main relation subject to non-repudiation
>services and their resolution is however always between the signing entity
>and the relying party. It is only they who in the end defines the exact
>meaning of a specifics non-repudiation service. The only reason for them to
>stay within the CA:s definition of non-repudiation is to have a possibility
>to make the CA liable for losses in some cases of disputes.
>
>However, any non-repudiation service has to stay within the general
>definitions, supplied by X.509 and PKIX, to expect any evidence value. This
>is why these definitions are so important.  
>
>Hope this helps in sorting things out.
>
>/Stefan


It does.  Thanks again.

___tony___




Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: azb@xxxxxxxx   phone: 510-422-3881             LLLLLLLL