Subject: Re: proposed key usage text

From: [email-masked]
Date: Fri, 19 Nov 1999 09:02:34 -0800

we are doing something like that for AADS radius (i.e. being able to upgrade
something like 99% of the current internet ISP authentication infrastructure to
digital signature authentication). The strategy is that the ISP sends a
challenge string ... basically somehting like "please authenticate 'userid'"
with a time-stamp/nonce (in lieu of the "please enter password" message), the
user then adds their own nonce, signs it and returns it. Having webserver
products at the large web farms also support radius ... then allows a single
authentication administrative infrastructure for the majority of existing
internet operations.

Aram Perez wrote:

> But how do you distinguish between what use was intended? If someone
> captures a message that I signed for "authentication and integrity" and
> another message that I signed for "non-repudiation", how does a third party
> distinguish which use was intended?
>
> I have seen many authentication protocols that require the party being
> authenticated to sign a challenge (that is supposed to be a random number or
> a nonce). Now suppose that I'm trying to get access to a system that instead
> of sending me a random challenge, sends me the following message: "I agree
> to sell 1000 shares of Apple at $10.00 per share." My software will blindly
> sign the message and send my certificate which has the DS and NR bits set.
> Am I now obligated to sell 1000 shares of Apple at $10.00? Can I prove to a
> third party that I was only trying to do authentication and not
> non-repudiation?
>
> Regards,
> Aram Perez

---

From: "Todd Glassey @ GMTsw" <[email-masked]>
Date: Fri, 19 Nov 1999 11:32:43 -0800

Lynn, I want to talk with you on the phine about CertifiedTime.com and what
it does. I believe that this is the only reliable time source in the
commercial world today and want to explain how and why what we do what we
do.

Our system is a commercial Timing Authority selling the setting of
commercial clients time and timebase services. We are a private company that
provides Trusted Third Party timesetting and this would be a good value at
FD's operating service models.

I suggest that we chat and setup a dog and pony.

Todd

---

From: Marc Branchaud <[email-masked]>
Date: Fri, 19 Nov 1999 13:17:44 -0800

I suggest that the presence of the nonce be the distinguishing factor in mere
authentication vs. non-repudiation.

If the intent is to sign for authentication, then the signer adds a nonce to
the blob being signed.

If the intent is to sign for non-repudiation, then there is no nonce.

		Marc

---

From: Terry Hayes <[email-masked]>
Date: Fri, 19 Nov 1999 13:26:37 -0800

> If the intent is to sign for non-repudiation, then there is no nonce.

I don't buy this.  It would be true if I (or actually my signing application)
recognized and verified every bit that was in the data being signed.  In this way, I
can tell that the bits correctly relate to the transaction in progress.  If there
are bits that are unknown to the signer (such as a nonce supplied by the other
party), then I can't tell if the other party is mounting some sort of attack by
varying bits in the message.

There are cases (SET is one example - but don't get started on that) where one party
signs references to data that it doesn't know to bind it to the rest of the
transaction.

I'd be much more comfortable adding a nonce in all cases.

Terry

---

From: Marc Branchaud <[email-masked]>
Date: Fri, 19 Nov 1999 14:48:49 -0800

I can sortof see your point, but how can you have any sort of non-repudiation
if the bits are unknown to the signer?  It seems to me that for
non-repudiation the signer has to digest the bits directly, and so doesn't
have to worry about being vulnerable to the kind of attacks you mention.

I know I would be very uncomfortable if my application had to sign some
random hash in a non-repudiable way.  I would very much want to see what I'm
signing first.

		Marc

Terry Hayes wrote:
> recognized and verified every bit that was in the data being signed.  In this
> way, I can tell that the bits correctly relate to the transaction in progress.
> If there are bits that are unknown to the signer (such as a nonce supplied by
> the other party), then I can't tell if the other party is mounting some sort
> of attack by varying bits in the message.
> 
> There are cases (SET is one example - but don't get started on that) where one
> party signs references to data that it doesn't know to bind it to the rest of
> the transaction.
>

---

From: Tony Bartoletti <[email-masked]>
Date: Fri, 19 Nov 1999 14:55:19 -0800

>random hash in a non-repudiable way.  I would very much want to see what I'm

Marc,

I can see a way around this, maybe.

Suppose the signer always has the opportunity to add a recognized
"RepudiableBinding" token as a nonce to what they sign.  Then, if
I must enter into a NR transaction, I must take care NOT to include
this token, else the transaction will be rejected.

The presence of the "RB" token "trumps" any other presumption of NR
that the transaction might otherwise imply.  In particular, the
signer can safely countersign "unseen challenges", though it would
require the challenging party to do a tiny bit of parsing upon
receipt of the signed challenge to ensure the original challenge
is contained.

___tony___

Tony Bartoletti                                             LL
IOWA Center                                              LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 089                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: 925-422-3881   fax: 925-423-8081               LL LLLLLLLL
email: [email-masked]                                   LLLLLLLL

---

From: "Todd Glassey @ GMTsw" <[email-masked]>
Date: Fri, 19 Nov 1999 15:18:19 -0800

My profuse apologies to the list, the CC window was hidden, Sorry Stephen,
this was not intended to have been posted

----- Original Message -----
From: "Todd Glassey @ GMTsw" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, November 19, 1999 11:32 AM
Subject: Certifiedtime.com

> it does.

Todd

---

From: Marc Branchaud <[email-masked]>
Date: Fri, 19 Nov 1999 17:26:16 -0800

I'm still not convinced that a nonce is needed in all cases, but your
proposal would work for me.

So, in the repudiable case, the bytes that get signed consist of

	- The digest or challenge
	- A nonce
	- The repudiation token

But in the non-repudiable case, the repudiation token is absent (replaced
with padding).

This sounds OK to me.  Why do I get the feeling that I'm missing some kind of
detail?

		Marc