Subject: RE: Meaning of Non-repudiation

From: [email-masked]
Date: Mon, 6 May 2002 09:58:51 -0600

somewhat as aside,  in theory the whole point of certificates & the
"certified" information is for use/reliance by relying parties.

having a

1) bit that says the sender believes that they are signing something with
no meaning (random data) and

2) diffferent bit that says the sender believes that they are signing
something with meaning (not random bits) containing some semantic meaning
with possible implication that the signing operation indicates the sender
is in some agreement with the contents of the signed message.

backing those bits out of the actual signed message and into an appended
certificate could work if there was an exact one-to-one correspondance
between the key doing the signing and the appended certificate. However, if
it is a certificate with both of the bits on ... then it is somewhat
defeating the purpose of having the bits .... because the relying party no
longer can rely on specific deterministic meaning (aka the sender believes
that they are signing something with no meaning ... or signing something
with meaning ... but relying party isn't able to tell which because both
bits are on, defeating the purpose of having the bits at all).

The other problem is being able to proove that sender has never acquired
multiple certificates for the same key pair with different bits set. Since
the appended certificates aren't part of the signed message ... the sender
could claim that they had appended the certificate with the  "no meaning
message" ... and somebody substituted a certificate  the "no meaning" bit
off and the "meaning" bit on. That problem then suggests two extremes:

1) never allow people to generate their own keys and supply them to 3rd
parties for certification. CAs can guarentee that key pairs are never
submitted for multiple certificates if they only certify random keys that
the CA generate themselves .. and that creating a new certificate always
requires generating a new key pair (unless there is a global repository
used by all CAs checking to see if a specific key-pair had ever previously
been certified).

2) moving the certificate inside the signed message. the reason to do this
is the original suggestion involving the flag bits indicating the senders
belief as to the flag indicating message type/characteristic  needs to be
part of the signed message. moving the whole certificate inside the signed
message is somewhat overkill just to get a couple bit indicators moved
inside. this solution requires a convention that signers always include
flags indicating their belief as to the type of message (people doing
brain-dead signing of messages w/o looking at the contents might get
themselves into situation similar to people signing blank checks or blank
pieces of paper).

previous pieces of thread:
http://www.garlic.com/~lynn/aadsm11.htm#5 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#6 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#7 Meaning of Non-repudiation

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 06 May 2002 18:42:47 +0200

Lynn,

A few words before going on vacations for the remaining of the week.

:-)

> is in some agreement with the contents of the signed message.

This is the general understanding. This meaning is backward compatible with
the current meaning.

> bits are on, defeating the purpose of having the bits at all).

Hence why a certificate with these two bits set together would be dangerous.

If the client is always under the control of the signer, this could work if
the client makes sure, before using the private key, that the protocol used
is "safe". An "unsafe" protocol would be a protocol where a server asks to
sign a challenge. A safe protocol would be a protocol where the server asks 
to sign both a random number chosen by the client and a challenge chosen by 
the server.
 
> off and the "meaning" bit on. That problem then suggests two extremes:

It is the problem of the signer (not of the CA) to make sure that when it
uses these two different certificates, two different keys are being used.

> themselves into situation similar to people signing blank checks or blank

This is roughly what is being done in RFC 3126 (Electronic Signature Formats
for long term electronic signatures) : an unambiguous reference to the
certificate is part of the signature, hence the full certificate does not
need to be directly protected by the signature.

This allows to work with multiples certificates that have both the same
public key and the NR bit set, but which contains different attributes.

The use of such certificates must always be restricted to environments 
(i.e. clients) that the signer can control.

Denis