Subject: RE: Signing what you don't understand

From: "Golkin, Ken (CAP, CMC)" <[email-masked]>
Date: Tue, 18 Jul 2000 08:44:40 -0400

This discussion seems to be confusing two different uses for certificates
1) Authentication (I am who I say I am)
2) Signature (I signed a legally binding document)

In the first case I showed my company issue picture ID (certificate) to the
guard at the door and he let me in the building this morning.  
In the second case I stopped at the hardware store on the way home last
night to buy a box of nails and some other things.  At the check out I
showed them my charge card (certificate) then signed the sales slip.  Which
legally obligated me to pay $24.86.  

The certificate policy (defined as: A named set of rules that indicates the
       applicability of a public key certificate to a particular
       community or class of application with common security
       requirements. For example, a particular certificate policy might
       indicate applicability of a type of public key certificate to the
       authentication of electronic data interchange transactions for
       the trading of goods within a given price range.) in X.509 PKiX
roadmap makes it clear that all certificates are not created equal.

The Canadian Government and United States Government PKI initiatives have
defined multiple levels of assurance, and as far as I can tell, most
business applications of PKI are following the government lead.

If I'm loaning someone $250,000 to buy a house I obviously need a greater
level of assurance that they are who they are (and their bank is who they
say they are) then was required by the checkout at the hardware store or the
guard at the entrance.

-----Original Message-----
From: Adrian McCullagh [mailto:[email-masked]]
Sent: Monday, July 17, 2000 11:08 PM
To: 'Stephen Kent'
Cc: [email-masked]
Subject: RE: Signing what you don't understand

Stephen,

I do not want to get into an argument with you.  Yes I am a lawyer but I
also have a technical background so your suggestion otherwise, I thought was
not moving the discussion forward. Admittedly, I do not possess the
technical knowledge that you have.

Your example is well put but is this really a digital signature or is it a
set of bits (a mark) that has been affixed using the same technology known
as digital signature technology.

You mention the difference between the 2 intents.  I would be surprised, if
anyone (other than the technically minded) even knows that a challenge
response is even being "signed".  There is no intent at all in this case. It
is the technology as designed that is effecting the response to the
challenge.  I am surprised that "you" sign authentication challenges, just
for authentication purposes.  Is it really a signature?  Are you really
signing the authentication challenge or is it the software on your machine
effecting the response to the challenge? 

To me this is not a signature.  It may use digital signature technology but
it is not a signature.  This is probably the problem.  It is the use of the
word "signature" which is a technical term but has been used by the PKI
community to cover a myriad of uses.  Some uses of the term by the PKI
community are confusing. 

I also do not agree with your position that the NR bit can signal any intent
either way.  With respect, intent is ascertained at the time of signing.  A
certificate has nothing what so ever to do with signing.  Its primary
purpose is to identify a public key that corresponds to a private key that
may be held by some previously identified person or entity.  The public key
is used to verify a digital signature that has supposedly been created using
the corresponding private key.  That is it as far as I understand it unless
there is some other primary purpose that I do not know.  I do not see the
relationship between digitally signing a document and the contents of a
certificate. Verification of the signature at some later time is a different
issue which may involve the use of a certificate but this may not be so.

Adrian McCullagh
Director of Electronic Commerce		Tel: 617 3231 1522
Gadens Lawyers					Fax: 617 3229 5850	
level 39
Central Plaza 1
345 Queen Street
Brisbane Australia 4000

Ph. D. Candidate 
Thesis "The Incorporation of Trust Strategies in Digital Signature
Regimes for Elec. Comm."
Information Security Research Centre
Queensland University of Technology

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Tuesday, July 18, 2000 10:00 AM
To: Adrian McCullagh
Cc: [email-masked]
Subject: RE: Signing what you don't understand

At 12:50 PM +1000 7/15/00, Adrian McCullagh wrote:
>Stephen
>
>I really do not understand your response.  Why would anyone sign a document
>that they do not understand.  It does not make sense.  If I sent you a
>document written in Chinese and assume you can not read Chinese and at the
>same time I said just sign this - Why would you sign it.  Now if you
trusted
>me then you may sign it based upon the information about the document that
I
>tell you.  A classic case for Non-est-factum.  But all the cases that I
have
>read clearly rely upon some information provided by an Alleged trusted
third
>party.  Usually some relative.  So without some external information being
>provided by a third party it is not as far as I can determine possible to
>rely upon non est factum.

Because we sign authentication challenges, just for authentication 
purposes, but not for NR purposes, it is prudent to distinguish 
between the two intents.  Your comments seem to ignore this use of 
digital signature technology. One way of signalling intent is via the 
NR bit. Although it has been argued that having this bit set to True 
does not necessarily signal intent to sign for NR purposes, having it 
set to False certainly signals an intent to not be bound re NR.

(Your use of Latin and your e-mail "signature" suggests a legal, but 
perhaps not a technical background. We've also decided, after much 
debate, that PKIX deals with technical aspects of NR, not legal 
details that may vary based upon jurisdiction.)

>Also what does a "bit" in a certificate got to do with non-repudiation.
The
>commercial world and the law does not in my opinion support this position
of
>yours.  You appear to be on a path to re-engineering the entire commercial
>legal fabric and as such I with the greatest respect I do not  believe that
>society and the law will buy into it.  With out the commercial involvement
>PKI will not survive.

The position is not just mine.  Sorry of you don't understand, or 
merely don't agree with the use of the NR bit, or its name, but we 
had this debate a while ago and we're not having it again.

>
>I do not understand how - "what you are proposing" - will work in practical
>terms.

I'm not "proposing," but I am citing existing Internet and ITU 
standards and the applicability to the question at hand.

Steve

---

From: "Mitchell Arnone" <[email-masked]>
Date: Tue, 18 Jul 2000 12:00:14 -0400

I am sure I don't have the background in PKI as most of those
contributing to this list but I would like to share some ideas:

I have a hard time imagining use of digital signatures for anything that
does not require Non-repudiation.   There are a number of NR issues
addressed with digital signatures including NR related to the creation
of an object as well as Non-repudiation of activities such as
delivery/receipt of messages, knowledge (proof that a message was read),
and much more.  Sometimes I feel that the term "signature" creates a
paradigm that can become difficult to transcend but I cannot come up
with a better descriptor of the intent behind the process.

As for authentication, digital signatures (which requires access to the
private key, Not a Digital Certificate) demonstrates proof positive that
"a person is who they say they are" and provides a means by which
unquestionable proof can be established that the owner of a given
certificate responded to a challenge and subsequently gained access to
some secure resource.  It it important to remember that a digital
certificate is public in nature and without the corresponding private
key, it is meaningless.  When a challenge is issued in the
authentication process, the act of signing that challenge must manifest
itself by requiring the user to submit his or her passcode to unlock the
private key.  If there is no challenge (i.e. the process of signing
without the knowledge of the owner of the certificate) then the
authentication process is completely invalidated.

The following is a quote from FIPS 196:

"To acceptably implement this standard, an implementation must meet the
following criteria:

1) Each entity in an authentication exchange must use a FIPS approved
digital signature algorithm to generate and/or verify digital
signatures;

2) Each entity must generate (pseudo)random numbers using a FIPS
approved (pseudo)random number generator;

3) Each entity acting as a claimant must be bound to a public/private
key pair; the private key should remain in the sole control of the
claimant who uses that key to sign a random challenge. The key binding
requires a unique authentication identifier for each claimant, so that a
verifier can distinguish between multiple claimants; and

4) One or both of the authentication protocols in this standard must be
implemented. For each protocol, steps and token fields marked as
[OPTIONAL] do not need to be implemented, except where indicated
otherwise. However, all other steps and token fields must be
implemented."

In my mind, authentication and digital signatures are inseparable and we
would be better served to refrain from focusing on the granular
differences.

Mitchell Arnone
PKI Engineer

"Golkin, Ken (CAP, CMC)" wrote:

> In the first case I showed my company issue picture ID (certificate)
> to the guard at the door and he let me in the building this morning.
>
> In the second case I stopped at the hardware store on the way home
> last night to buy a box of nails and some other things.  At the check
> out I showed them my charge card (certificate) then signed the sales
> slip.  Which legally obligated me to pay $24.86.
>
> The Canadian Government and United States Government PKI initiatives
> have defined multiple levels of assurance, and as far as I can tell,
> most business applications of PKI are following the government lead.
>
> If I'm loaning someone $250,000 to buy a house I obviously need a
> greater level of assurance that they are who they are (and their bank
> is who they say they are) then was required by the checkout at the
> hardware store or the guard at the entrance.
>

---

From: Tony Bartoletti <[email-masked]>
Date: Tue, 18 Jul 2000 10:59:48 -0700

Ah, that life were really so simple ... :)

At 12:00 PM 7/18/00 -0400, Mitchell Arnone wrote:
>I have a hard time imagining use of digital signatures for anything
>that does not require Non-repudiation.

On one level, I can agree with this statement.  One wants to say
"What other purpose for applying an (assumably unforgeable) mark
other than to have it be unforgeable?"  And as I have argued long
previously, the "math of it" gets you this much, regardless of the
setting of key-usage bits or other implied intent.

But that is really not saying very much.

What (other than certification, to start with) attaches this
disembodied signing-key to an "actor"?

>some secure resource.

This assertion WAY overstates the strength of the situation:

If I can fool a CA (with fake driver's license, etc) into certifying
my key-pair as "belongs to Mitchell Arnone of b2bcommunications.com",
does my use of this key provide "proof positive" that I am who I say
I am?  Or equivalently, proof that the real Mitchell took action?

And would it matter that, when invoking a signature, that I must use my
personal passcode to unlock MY (presumably, your) signature key?

To clear one's head, begin with the understanding that the application of
(and verification of) a (mechanical) digital signature serves (effectively)
as proof positive of three central facts:

a.  The "wielder of the signature" (person or process) indeed possessed
     the secret-key corresponding to the public key used in verification.

b.  Some "process" had access to both the secret-key, and the document
     (or the hash of the document.)

c.  The document (or hash) verified is exactly the document (or hash)
     that was mechanically signed. (No tampering took place.)

Now, we would like "wielder of the signature" to have a more substantial
form of identity.  We attempt to create this "sense of substance" by the
use of certificates.  But there are clearly wide variances by which this
certification may proceed, and from which assertions can flow.

>would be better served to refrain from focusing on the granular differences.

"Agree in Principle" ... however ...

Contrast "signing important legal contract" with "signing receipt of email".

The former should (likely) require an active and duly witnessed
"live person", and a trusted display device that guarantees that
what is signed is precisely no more and no less than what is being
displayed, and further displays the particulars of the key-ownership
certificate, to help ensure that the "witnesses" are not being fooled
into attesting to my signing with your key.  Expensive technology.

The latter is a useful application of "digital signature mechanics"
that I might employ to let people know that "their mail was delivered
to the right address".  I might configure my mailer to create such
return receipts automatically, even while I am away.  In such a case,
is it True or False that the application is "signing without the
knowledge of the owner of the certificate?"  Depends upon perspective.
Was there a sufficient "challenge"?  Was it enough to effect that
challenge (only) during my act of configuring my email-robot to
employ the key?  Should the act of configuring my email-robot require
witnesses and the expensive secured display device described above?

If such strong measures are unneeded for this application, how
can one ensure the code or process is not subverted to effect
signatures for contracts (or arguably so, to repudiate a former
signature made with a stronger technology.)

Alternatively, do you argue that "email return receipts" should
remain "unsigned" by a technology so "strong"?

___tony___

>>In the first case I showed my company issue picture ID (certificate) to 
>>the guard at the door and he let me in the building this morning.
>>
>>showed them my charge card (certificate) then signed the sales 
>>say they are) then was required by the checkout at the hardware store or 
>>the guard at the entrance.
>>
>>From: Adrian McCullagh 
>>[<mailto:[email-masked]>mailto:[email-masked] 
>>ns.com.au]
>>From: Stephen Kent [<mailto:[email-masked]>mailto:[email-masked]]

Tony Bartoletti 925-422-3881 <[email-masked]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900

---

From: Eric Rescorla <[email-masked]>
Date: 18 Jul 2000 09:37:31 -0700

"Mitchell Arnone" <[email-masked]> writes:

> [1  <text/plain; us-ascii (7bit)>]
> does not require Non-repudiation. 
Then you're not imagining very hard. As previously noted,
digital signatures are used all the time in non non-repudiation
contexts. For instance, for verifying the authenticity of
keying material in IKE handshakes.

-Ekr

[Eric Rescorla                                   [email-masked]]

---

From: Eric Murray <[email-masked]>
Date: Tue, 18 Jul 2000 18:47:19 -0700

> keying material in IKE handshakes.

Just to make it really clear (because it's obviously not clear to
some people), there's "digital signing" in the human/legal
sense, and "digital signing" in the crypto sense.

Digital signing in crypto sense means applying an encryption function to
a number and a private key, such that any holder of the public key that
corresponds to the private key can decrypt the number.  If that number
is a hash of a document, then the party doing the verification can do
their own hash and compare the values.  (yea, I know there's other ways
to do a signature, but this is the most common).  You can also sign a
nonce or keying material as part of a protocol to prove identity or to
set up a secure channel.  Repudiation of those things, especially the
exchange of keying material, doesn't make sense.

Digital signing in the human/legal means signing something different.
It always means "signing" something that makes sense to a human.  It might
mean using the crypto definition of "digital signing" to do it, or (under
the new US "digital signing" bill) it might mean clicking on a OK button
somewhere near the document.  This kind of digital signature 
makes sense in a non-repudiation context- it's whole purpose is about NR.

Since "digital signing" is used all the time in the crypto sense, I'd
like to propose that when talking about the second kind of digital
signatures, they be called "digital signature of documents".

I know this is obvious to a lot of people, but now having stated
the obvious, there's no excuse for anyone here to mistake one kind of
digital signature for the other.... you'll have to find something
else to split hairs about now. :-)

-- 
 Eric Murray www.lne.com/ericm  ericm at the site lne.com  PGP keyid:E03F65E5
Security consulting: secure protocols, security reviews, standards, smartcards.

---

From: Ben Laurie <[email-masked]>
Date: Wed, 19 Jul 2000 10:21:34 +0100

> signatures, they be called "digital signature of documents".

How about "legally binding digital signature". That certainly says what
people want it to mean unambiguously.

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

Coming to ApacheCon Europe 2000? http://apachecon.com/

---

From: Michael Fritscher <[email-masked]>
Date: Wed, 19 Jul 2000 13:42:04 +0200

> people want it to mean unambiguously.

An other way of distinguishing between those two meanings of "digital
signature" seems to me the use of the terms "electronic signature" and
"digital signature" ETSI uses in its standard on Electronic Signature
Formats (ETSI ES 201 733) and some others, too.

As far as I understood, 

* "digital signature" is used for the "data appended to, or a
cryptographic transformation of, a data unit that allows a recipient of
the data unit to prove the source and integrity of the data unit and
protect against forgery (taken from ISO 7498-2)" -> i.e. the technical
part

* whereas "electronic signature" is used for the electronic analogy to
"real-life" signatures with the adequate legal consequences including the
signature policy, the signed user data, the digital signature and "other
signed attributes provided by the signer" (see ch. 4.2 of ETSI ES 201 733
V1.1.3) -> the legal/human mean

Cheers,
Michael Fritscher

-- 
------------------------------------------------------------
| Michael Fritscher	[email-masked]
| Department of Information Systems, New Media
| Vienna University of Economics and Business Administration
| http://wwwi.wu-wien.ac.at/people/Fritscher.html
| "A computer without windows NT is like a fish without a 
|  bicycle."
------------------------------------------------------------

---

From: "P.J. Ponder" <[email-masked]>
Date: Wed, 19 Jul 2000 18:32:34 -0400 (EDT)

The Internet Security Glossary (RFC2828)

ftp://ftp.isi.edu/in-notes/rfc2828.txt

does a pretty good job distinguishing between 'digital signature' and
'electronic signature'.  Maybe those definitions are adequate for this
discussion.  (I was also under the impression that the Glossary itself was
a product of this workgroup...)

---

From: Tony Bartoletti <[email-masked]>
Date: Wed, 19 Jul 2000 16:16:13 -0700

> > people want it to mean unambiguously.

Since most "digital" signatures are "electronic" in implementation,
I find the term "electronic signature" equally confusing, in that it
does not (automatically) imply the burden of legal binding in the
minds of most people.  "Legal" or "Legally Binding" is far clearer.

In any case, while it is facile to establish an agreed terminology,
it serves only to sharpen the discussion of the issue at hand.  Given
that (electronic, legal) signatures will likely be founded upon the
cryptographic "digital signature" operation, how best to distinguish
the "DigSig" intent, to the protection of all parties concerned?

So far, I have heard:

   1.  Dedicated Key

         (implies one-key <--> one cert, and use NR-bit disambiguation)

   2.  Common Key + "signature over intended certificate"

         (implies one-key <--> many certs, and use NR-bit disambiguation)

   3.  Common Key + "look at the content"

         (implies "who needs the NR-bit")

Given that a public key must be assumed "public", I don't see any way
to enforce the one-to-one condition in the "Dedicated Key" option (1).

I think (2) is a minimum.  If something is digitally signed, and
the "signed content" does not include a certificate indicating the
the "level of intensity" with which "someone" (the CA) attested to
the strength of the DN/truePerson association, I would argue that a
relying party will (should) be disadvantaged in court.

Such a key should be safe for "non-binding" authentication usage,
since additional "weaker certification" of the key does not in
itself weaken the stronger DN/truePerson binding.

(NOTE: such non-binding authentication usage can be argued to
encourage deployment of the secret key in relatively unsecured
environments, and this IS a problem.  However, (to my knowledge)
the CA generally is not certifying the manner in which the
subscriber protects the key, so I cannot see how it becomes
an issue for them.)

___tony___

---

From: Stephen Kent <[email-masked]>
Date: Wed, 19 Jul 2000 14:32:12 -0400

Ken,

>to the guard at the door and he let me in the building this morning.

Or, maybe you "signed in" as part of entering your workplace, ....

<snip>

Steve