Subject: RE: Signing what you don't understand

From: Michael Zolotarev <[email-masked]>
Date: Wed, 12 Jul 2000 10:32:47 +1000

Denis,

> 
> It is my proposal that a signature format is designed which 
> will allow an
> entity to say: "I signed this data, but I didn't understand 
> what I signed.
> You are free to use this signature as proof that I possess a 
> certain private
> key, but this is also the only purpose for which this signature can be
> used."
> 
> Currently, I am not aware of a signature format that allows 
> an entity to do
> that. And because there is no such signature format, people 
> are constantly
> going ahead and signing data they don't understand anyway! 
> Smart cards, as
> currently used, are a perfect example of this behavior(*).
> 

I really fail to see how a potential security vulnerability of signing
environment is linked to a person's ability to say 'I sign it blindly, and
my signature bears no legal obligations'.

Those are completely different and unrelated things, IMHO.

Are you trying to say that because a system can be easily compromised for
25.000 (is it USD?), a person will be better off by using 'non-binding'
signature? This does not make much sense to me. Why not to simply say "Do
not sign anything at all, unless you are 100% sure that this world is free
of hackers"?

Forget about the technology for a moment. Think about legal implications of
it. Not a single court on earth would buy your argument about 'non-binding'
signatures. If you sign something, you are legally bound. When you are drunk
and sign a slip produced by a pizza-delivery boy - that's it, mate. You are
legally bound. Try telling to the court that your 'inner-security' could've
been compromised (not by a virus, but by alcohol), and therefore your
signature is 'non-binding'. 

Following this logic, we'd better start from global revision of the legal
system.

Regards
Michael

---

From: Frank Balluffi <[email-masked]>
Date: Fri, 14 Jul 2000 20:38:18 -0700

Adrian,

I do not think Steve is advocating anyone sign a document they do not
understand. I think he is saying a signature by itself is not binding to a
person or a device. A certificate binds a signature to a person or a device.

Frank

> -----Original Message-----
> From: Adrian McCullagh [mailto:[email-masked]]
> Sent: Friday, July 14, 2000 10:51 PM
> To: 'Stephen Kent'; [email-masked]
> Cc: [email-masked]
> Subject: RE: Signing what you don't understand
> 
> 
> 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.   
> 
> 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.
> 
> I do not understand how - "what you are proposing" - will 
> work in practical
> terms.
> 
>  
> 
> 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: Thursday, July 13, 2000 11:49 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: Signing what you don't understand
> 
> 
> Denis,
> 
> >The most important point of my previous message was buried 
> under a pile of
> >other stuff, so I am repeating it here:
> >
> >
> >You are free to use this signature as proof that I possess a certain
> private
> We have had an analogous debate on this list last year.  This is one 
> motivation for the use of the non-repudiation bit in certificates, 
> i.e., if this bit is NOT asserted, one can reasonably interpret the 
> signature as not binding.  This does not require a change to the 
> signing format, but rather appropriate use of key usage bits in 
> certificates. As others have pointed out, the preferred way to 
> represent the distinction between binding and non-binding signatures 
> is via flags in certificates, e.g., key usage, cert policy, etc.
> 
> Steve
>

---

From: Khaja Ahmed <[email-masked]>
Date: Sun, 16 Jul 2000 16:20:58 -0400

Perhaps I have not followed this thread in its entirety and if this has
already been sorted out please ignore this but...

I am wondering if it is meaningful to discuss digital signatures without
considering things like:

1.) The applicable certificate policy.
2.) Was nonRepudiation enabled in KeyUsage
3.) The governing law under which the certificate has been issued and is
being used.  (Closed contractual community vs. local / regiona / national
law)

I am not sure what we will learn from this dicussion without these facets
added to it.

Do the above account for automatic signatures? Is it expected (indeed
required) that the signer have (demonstrably) full knowledge of what was
being signed?

Do people think it is worth our while (or even possible) to take a
hypothical certificate policy, add some assumptions about governing law  and
see where this discussion goes?

At Identrus we are examining this issue in the context of our own policies
and governing law and would like to see what the collective wisdom of this
group brings to light.

Thanks and Regards.

Khaja
=========================================== 
Khaja E. Ahmed 
Chief Technology Officer
Identrus, LLC. 
16th Floor 
140 E 45th St. 
New York, NY 10017 USA 
Telephone: 01.212.622.0673 
Fax: 01.212.622.9196 
[email-masked] 
Office Direct: 01.925.989.6564 
Office Main: 01.212.622.1524 
============================================ 

-----Original Message-----
From: Eric Rescorla
To: Adrian McCullagh
Cc: 'Stephen Kent'; [email-masked]; [email-masked]
Sent: 7/15/00 1:09 AM
Subject: Re: Signing what you don't understand

Adrian McCullagh <[email-masked]> writes:
> I really do not understand your response.  Why would anyone sign a
document
> that they do not understand.  It does not make sense.
People perform digital signatures of data they don't understand all the
time. One most common case is cryptographic protocols which use
digital signature for authentication of various kinds of keying
material. (SSL and IKE both do this). Note that these signatures
are often completely automatic.

Now, as a matter of cryptographic practice, one generally arranges
that neither party completely controls the input to the signature to
to prevent one party from forcing another to sign an arbitrary
document. However, as a matter of defense in depth, it's also nice
to have those keys tagged in such a way that even if the protocol
protections were broken, the signature still couldn't be used against
the signer.

Part of the issue here is that digital signature is a cryptographic
primitive that can be used for other purposes than those which
holographic signatures are currently used.

-Ekr

[Eric Rescorla                                   [email-masked]]

---

From: Khaja Ahmed <[email-masked]>
Date: Mon, 17 Jul 2000 12:52:45 -0400

>Anything in the certificate that's used to imply something about the
>intent
>behind a signature is asking for trouble, unless the specific
>certificate
>that a relying party should use is bound to the signature.  What's to
>prevent me from obtaining certificates from two different CAs,
>certifying
>the same key, but with different settings of the NR bit in the two
>certificates, and then using the certificate with the NR bit clear to
>repudiate a signature I originally represented as being non-repudiable
>using the other certificate?

Does this make a case for keys generated in hardware that prevents cloning
and backup?  That would in turn imply that legally defensible NR comes at a
fairly steep price.

>The only way that using anything in the certificate could work is if the
>specific certificate that I intend a relying party to use to verify the
>signature is somehow bound into the signature.  Binding a particular
>certificate to a signature has all sorts of other problems (e.g. do all
>my
>signatures become unverifiable when my certificate is renewed?), and
>would
>require a signature format change anyway, so why not simply assert the
>intent explicitly as part of the signature?

Are there any proposals to do this?  Are there revisions being contemplated
to signature formats that include the certs?  I find this very interesting
and would like to know if any work is being done in this area.

Thanks.

Khaja

Stephen Kent <[email-masked]> on 07/13/2000 09:48:56 AM

To:   <[email-masked]>
cc:   <[email-masked]>
Subject:  Re: Signing what you don't understand

Denis,

>The most important point of my previous message was buried under a pile
of
>It is my proposal that a signature format is designed which will allow
an
>entity to say: "I signed this data, but I didn't understand what I
signed.
private

Steve

---

From: [email-masked]
Date: Mon, 17 Jul 2000 13:39:41 -0400

John,

This why the Internet-Draft at
http://www.ietf.org/internet-drafts/draft-ietf-smime-esformats-00.txt
mandates the use of the "ESS signing certificate" attribute from RFC2634 to
bind the certificate and public key that a relying party MUST use to verify
a digital signature.

Francois

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, July 17, 2000 10:21 AM
To: Stephen Kent
Cc: [email-masked]; [email-masked]
Subject: Re: Signing what you don't understand

Anything in the certificate that's used to imply something about the intent
behind a signature is asking for trouble, unless the specific certificate
that a relying party should use is bound to the signature.  What's to
prevent me from obtaining certificates from two different CAs, certifying
the same key, but with different settings of the NR bit in the two
certificates, and then using the certificate with the NR bit clear to
repudiate a signature I originally represented as being non-repudiable
using the other certificate?

The only way that using anything in the certificate could work is if the
specific certificate that I intend a relying party to use to verify the
signature is somehow bound into the signature.  Binding a particular
certificate to a signature has all sorts of other problems (e.g. do all my
signatures become unverifiable when my certificate is renewed?), and would
require a signature format change anyway, so why not simply assert the
intent explicitly as part of the signature?

John

Denis,

>The most important point of my previous message was buried under a pile of
>It is my proposal that a signature format is designed which will allow an
>entity to say: "I signed this data, but I didn't understand what I signed.
private

Steve

---

From: Tony Bartoletti <[email-masked]>
Date: Tue, 18 Jul 2000 12:15:56 -0700

At 02:43 PM 7/18/00 -0400, Heimberg, Jim wrote:
>Are we moving in the direction of the Twilight Zone.  If you could fool the
>CA with a false driver's licence, why don't you just get the false ID, forge
>his checks, and raid his bank account?  The signature is a mark that is
>either accepted as being valid or is forged.  There is no difference with
>the digital signature.  Your digital signature is not any better or any
>worse than your pen-and-ink signature.  You decide when to use it.  If you
>receive a FEDEX, you sign for receipt, right?  If you receive an e-mail,
>what is different than signing to signify receipt?  That signature does not
>do the same thing as if you were signing the $10M contract contained in the
>FEDEX package or the one contained in the e-mail.  Where is the issue?
>Jim

The issues are really:

1.  How hard is it to obtain a false digital certification of a key,
     compared to other false credentials?

     If it is easy, we are indeed in the "Twilight Zone", and building
     rock-solid castles on a quick-sand foundation.

2.  If it is "variably hard" to obtain false digital credentials,
     depending upon chosen CA and "level" of certificate purchased,
     then one cannot "ignore the certificate" when assessing the
     "binding-ness" of a signature to a (presumably) intended act.

3.  If it is "variably hard" to assert the key is safely stored,
     or was expected to be safely applied by the "signing-device"
     then this simple result of "verification mathematics" buys you
     little with respect to assertions about the intent of a given
     signature, or the strength with which it was "intentionally
     bound" to a signed object.  More so, if one wants to hold all
     certificates as "equally strong" with respect to usage.

___tony___

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

---

From: Tony Bartoletti <[email-masked]>
Date: Tue, 18 Jul 2000 12:26:38 -0700

At 02:43 PM 7/18/00 -0400, Heimberg, Jim wrote:
>If you receive an e-mail, what is different than signing to signify receipt?
>That signature does not do the same thing as if you were signing the $10M
>contract contained in the FEDEX package or the one contained in the e-mail.
>Where is the issue?
>Jim

(I neglected this point)

Granted, no court of law will likely hold me to some forged $10M contract
based upon a simple digital signature.  But there is always an exploitable
grey area, even if only between $5, $50, $500, where it will be commonplace
to rely upon lightweight (digital) signature activity.

In such a case, how can you be sure that your browser, configured
to automatically sign (harmless) email receipts, does not become
subverted by a trojan plug-in to sign other things you may be
unaware of?  Especially so, if the "evidence" only demonstrates
"it was the same key, owned by you."

___tony___

---

From: "Ramsay, Ron" <[email-masked]>
Date: Wed, 19 Jul 2000 11:23:35 +1000

Hi,
 
I disagree. In fact, I believe that Adrian made a very clear point. He
referred to the act of 'signing', which he took to be an act that took place
in the world of people, not computers. It seems that, in the world of
computers, this relates to the explicit placing of a digital signature on a
document. It also invokes non-repudiation procedures which, while being
strongly debated, still are reasonably well understood.
 
Against this is the digital process that has been characterised as
authentication. In this process, I simply prove that I am 'me' or,
digitally, that I hold a particular private key. Perhaps the true difference
here is that the signature is applied to a challenge where, regarding
'signing', the signature is applied to a document.
 
I am happy with this distinction.
 
Some argue that it should be possible to apply a 'repudiable' signature to a
document. I think that this becomes a legal issue. Is it rather like, what
liability attaches to me when I sign for delivery. The usual answer is none,
really, it is simply a proof of delivery. In fact, someone else at that
address may have signed for it on your behalf. It is  probably true that
there is no such thing as a repudiable signature (in the sense of
'signing'), but one can reasonably expect that the legal situation will be
similar to the case now for bio-signatures. Technical uses of public key
algorithms for other purposes (authentication) should not be considered
'signing', as understood by non-technical people.
 
Ron.

-----Original Message-----
From: Mitchell Arnone [mailto:[email-masked]]
Sent: Wednesday, 19 July 2000 2:00
To: Golkin Ken (CAP CMC)
Cc: 'Adrian McCullagh'; 'Stephen Kent'; [email-masked]
Subject: Re: Signing what you don't understand

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: 

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]
<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 

-----Original Message----- 
From: Stephen Kent [ mailto:[email-masked] <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

>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 

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: "Golkin, Ken (CAP, CMC)" <[email-masked]>
Date: Thu, 20 Jul 2000 08:51:45 -0400

I didn't sign in and most importantly there is persistent record of me
having entered.  There are other places that I have "signed in" and there
are indeed persistent records there.

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Wednesday, July 19, 2000 02:32 PM
To: Golkin, Ken (CAP, CMC)
Cc: [email-masked]
Subject: RE: Signing what you don't understand

Ken,

>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.

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

<snip>

Steve

---

From: [email-masked]
Date: Thu, 20 Jul 2000 10:12:54 -0400

I've been monitoring this discussion for a couple of weeks.

May I offer an example to try to crystallize a key point of this discussion?

Assume I am negotiating the language of a contract with a third party and my
purchasing department.  We may send numerous drafts back and forth as e-mail
attachments, in an effort to arrive at agreeable language.  Obviously I can
digitally sign each draft of the contract document before attaching it, just to
make sure no third party substitutes language in my name.  It should be clear
that in doing so, however, I have not "signed the contract" in the normal sense.

Now assuming that all parties accept digital signatures as binding, the question
is how do I sign it differently when I mean to execute the contract?

That is the crux of the matter.  In protecting the drafts, I am neither signing
something that I do not understand, nor am I not executing a contract.

Seems to me absent some elaborate schemes involving multiple keys, the answer is
that the content and context must be used to determine the intent.   It could be
argued that in this instance, if the contract document contains "DRAFT", or does
not have my name in the document on a signature line, then it could be expected
that a reasonable person (or court) would correctly infer that it was merely a
digitally signed document, not a legally signed contract.  But what if the final
draft does not say DRAFT, and has the signature lines filled in?   That is the
problem, and I think its resolution is in the realms of evolving practices,
legislation and case law, and cannot be addressed completely by a technical
spec.

With transactions that are not direct equivalents of paper contracts, the issues
get even murkier, but perhaps commonsense practices could be proposed to include
an explicit acknowledgement of the intent to be bound within the material being
signed.   In an online ordering system, this could be a prominent notice such as
"By proceeding, I understand that I am entering into a contract to buy the
widget."  along with a completed NAME field that can be matched to the name
bound to the verification key.

Byron

---

From: "Anders Rundgren" <[email-masked]>
Date: Thu, 20 Jul 2000 17:14:31 +0200

Paul,

> Anders> Piers,
> >> I would welcome comments from this forum on their opinion of the
> >> validity of signatures where the private key and end-user are not
> >> co-located.
>
> Anders> This is now for real as VISA-EU has lost faith in the
> Anders> original SET model with local key/cert and will aggresively
> Anders> push a server-based model.  Way to go IMO!
>
>What does that mean?

It means that the SET card-holder certificate+private key is stored and
excuted on the customer's bank instead of in his/her PC,  Why do that?

This I have talked about several times on this list so I will not go into
details but this one is easy: Most potential customers already have an Internet-
bank facility that uses some kind of proprietary security solution.  In
Sweden most banks use a hardware box like secureID or Activecard.
With the Server Wallet you use the same security solution for credit-card
payments.  Assuming that the issuer is the very same bank which is true
in 99 cases out of 100.  A small step closer to SSO [Single Sign On] :-).

I.e. you redirect the merchants's payment request to your bank and
authenticate to the cert/key using a bank-specific security solution and
then the bank does the rest.   All communication is shielded by SSL of course.

> Anders> But this was maybe more than you asked for, beacuse the
> Anders> signatures are also created on the server (wallet) which is
> Anders> not the same as downloading private keys when needed.
>
> Anders> In German unfortunately:
>
> Anders> http://www.visa.de/df/presse/pressetexte/000619_001.htm
>
>Unfortunately that document doesn't actually say anything.  It's just
>marketing vapor.  
>
>Do you have a reference that contains information?

Currently not.  This is information gathered from Commerce.Net and it does
not contain very much technical details.  However, I have confirmed that it
works as describe.

Anders

---

From: Frank Balluffi <[email-masked]>
Date: Thu, 20 Jul 2000 07:39:59 -0700

> bound to the verification key.

I agree.

Please note Byron's use of "explicit" above. Every meaningful document that
I have ever signed has explicitly included one or more verbs. There is no
reason why explicit verbs cannot or should not be included in signed
authentication responses. For example, "I received the following bytes ..."
could be signed. Just because authentication protocols exist that include
implicit verbs does not mean this is good practice. If explicit verbs are
included, I really do not see a difference between signing an authentication
response, a credit card slip [or whatever it is called] to purchase a pizza
or a purchase order for a jet aircraft.

Frank

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, July 20, 2000 10:13 AM
> Cc: 'Stephen Kent'; [email-masked]

---

From: [email-masked]
Date: Thu, 20 Jul 2000 18:11:00 -0600

Peter,

The Novell Certificate Server is included with every copy of NDS, and thus is potentially available to some 50 million users, plus or minus.  Although I certainly wouldn't claim that all of those customers are using our certificate server, they could, and for free, using servers running on NetWare, NT, and Solaris. 

For a number of reasons, including a certain mistrust of both the physical  security, computer security, and  cryptographic security of existing browser and e-mail implementations, together with the requirement to do _something_ about business key recovery for encryption and mixed usage keys, we made the decision to generate such keys on the (normally more secure) server, and then download the keys securely to the browser or e-mail client for use.

I can hear the screams now -- "but the system administrator might have access to my keys in that case" -- and that is true, and deliberately so.  And by the way, at least in most corporate environments, the system administrator is also the guy who installed the browsers, configured the operating system, specified what roots are to be trusted, etc..  It's not that I trust systems administrators for everything under the sun, but you can hardly expect the secretaries, clerks, or even the General Counsel or CEO in most corporations to have a Ph.D. in computer science/cryptography AND have the time to do all of this stuff themselves.  And of course, if our certificate server doesn't meet their needs, they can go pay lots of money to someone else.  It's a free product -- if they don't like it, we'll cheerfully refund what they paid for it.

Having said that, there are a couple of caveats.  First, these keys are primarily used for authentication to corporate resources that are under the control of the system administrator in any case, and secondarily for use in encrypting internal e-mail, for which the company may choose to assert a business key recovery right and responsibility.

Secondly, in part due to my frustration in not having an agreed-upon definition for nonrepudiation, and in particular the semantic requirements as to what to do or not do when presented such a certificate, the Novell Certificate Server does not at this time create certs with the NR bit asserted.  

Whatever the NR bit is finally determined to mean, it will almost certainly call for a higher level of trust than what is currently provided within existing browsers and e-mail packages, which at present is our primary market segment.

I hope that clarifies the issue somewhat.

Regards,

Bob

Robert R. Jueneman
Consultant Engineer, PKI/Security Architect

Novell, Inc. -- the leading provider of Net services software
1800 South Novell Place
Provo, UT 84606
www.novell.com

[email-masked]
1-801-861-7387

DISCLAIMER:
  If this message (with or without attached documents) is digitally signed, and/or if certificates are attached, the intended purpose is to 
   (1) Ensure that e-mail came from the apparent sender
   (2) Protect e-mail from tampering
   (3) Ensure that the content of e-mail sent to me and encrypted in  my dual-use key cannot be viewed by others.
  It is explicitly NOT the intent of any such signed message or document to represent any type or form of legally binding contract or other representation, and any such interpretation should not be considered commercially reasonable and will be repudiated, notwithstanding any wording or implications to the opposite effect in the text of the message itself.

>>> Ronald A Martin <[email-masked]> 07/20/00 02:20PM >>>
Another...

http://www.rsasecurity.com/products/keon/advancedpkiservices.html

    Ron

Anders Rundgren wrote:

> Peter,
>
> >> Several leading PKI vendors have implemented systems where the private key
> >> is held on a central Web server and then downloaded at run time to a web
> >> browser.  Are you saying that signatures created using these keys are
> >> invalid?
> >Are you sure? Could you provide a reference? I doubt that strongly...
> >
> >Peter
>
> I think this is one...
>
> http://www.arcot.com/products/webfort.html
>
> Anders

---

From: "Ramsay, Ron" <[email-masked]>
Date: Fri, 21 Jul 2000 14:48:08 +1000

Very interesting. It would have been interesting to have heard from Warwick
on the issue of non-repudiation. Verisign would seem to have placed a stake
in the ground.

Ron.
-----Original Message-----
From: Peter Williams [mailto:[email-masked]]
Sent: Friday, 21 July 2000 12:52
To: 'Richard Levitte'; Anders Rundgren
Cc: Peter Lipp; [email-masked]; [email-masked]
Subject: RE: Signing what you don't understand

http://www.verisign.com/press/2000/roaming.html

"VeriSign's revolutionary technology allows an end-user to securely 
store digital certificates and/or any other type of data, such as 
financial information or an online patient record, on distributed 
network servers operated by multiple trusted service providers. This 
technology enables portability of digital certificates, providing 
convenience for users to access and download their certificates and 
private keys for online authentication. It also enables the generation 
of binding digital signatures for conducting high-value e-commerce 
transactions, regardless of whether users are accessing the Internet 
from work, home, or another location such as an Internet kiosk. Digital 
certificates are electronic credentials that identify parties online, 
enabling encrypted communications and legally binding, valid digital 
signatures. 
"
 
-----Original Message-----
From: Richard Levitte [mailto:[email-masked]]
Sent: Thursday, July 20, 2000 11:24 AM
To: Anders Rundgren
Cc: Peter Lipp; [email-masked]; [email-masked]
Subject: Re: Signing what you don't understand

> http://www.arcot.com/products/webfort.html

I think not, at least from reading the papers "Protecting Digital
Identities" and
"Protecting Your Private Key".  All they say is that they've invented some
kind
of key database ("key wallet" to use their term) that is more secure than
what
comes with for example MSIE and Netscape Communicator...

Personally, if I was confronted with a CA that wanted to create my private
key
for me, and store it centrally to boot, I'd go somewhere else.  Very fast.
It
contradicts anything even remotely close to being called "secure".

--
Richard Levitte   !!! New cell phone number !!!
[email-masked]

/* You might enjoy viewing the complete vCard */

---

From: "Bob Jueneman" <[email-masked]>
Date: Fri, 21 Jul 2000 08:53:53 -0600

I can't tell from the brief description, but it appears that they are using a simple password to log on sequentially to multiple sites, and then assembling the collected secret shares at that point.

Granted that this makes it impossible for a rogue administrator at one institution to access a user's keys, but what is to prevent an attacker from collecting the shares himself, using a multiplicity of simple passwords?

Even if the user is scrupulous about using a different password for each server (making it very difficult to remember them all), the effort to break the system would seem to be merely additive, rather than exponential.  Guessing the or four simple passwords is still simple.

I must be missing something.  Does anyone have the patent application, or further details?

Bob

>>> "Ramsay, Ron" <[email-masked]> 07/20/00 10:48PM >>>

Ron.

---

From: Aram Perez <[email-masked]>
Date: Fri, 21 Jul 2000 09:06:15 -0700

Hi Peter L.,

>Are you sure? Could you provide a reference? I doubt that strongly...

Sorry for the delay, but I thought someone on PKIX had mentioned something
on this and it took me a while to find it in the PKIX archives. Partly
because these keys are referred to as one of the following: mobile or
roaming credentials. Anyway, on 15 Mar 2000, Magnus Nystrom wrote:

"Please find attached to this email a memo discussing the use of and
potential need for a PDU format and associated protocol for down- (and
potentiall up-) load of personal credentials, such as private keys and
X.509 certificates.

Stephen Farrell of Baltimore is likely to give a presentation on this
subject at the upcoming IETF meeting in Adelaide. We are currently
unsure of whether this would be a work item for PKIX or for some BOF
(or at all), but at least it seems as if this mailing list would be a
good starting point. Comments are of course welcome and solicited."

On 3 Jul 2000, Stephen Farrel wrote:

"I put up a slide in Adelaide about roaming credentials and it
looks like we're on for a BOF in Pittsburgh (date TBD). The
strawman charter/BOF description is attached. So, if you're
interested then subscribe to the list and let's see how much
progress we can make prior to Pittsburgh.

Paul Hoffman has kindly agreed to host the mailing list which
he'll open for postings in a day or two, as soon as subscribing
is seen to be working without problems, (but you can subscribe
right now). Paul's also hosting the web site at:

           http://www.imc.org/ietf-sacred

If you have any questions in the meantime, feel free to
mail Magnus and/or me directly."

Regards,
Aram Perez

---

From: Aram Perez <[email-masked]>
Date: Fri, 21 Jul 2000 10:07:46 -0700

Hi Peter S.,

[snip]
> An interesting part in the ETSI standard and the
> Internet-draft is the following reference:
> 
> 
> [TSP] C. Adams, P. Cain, D. Pinkas, R. Zuccherato. Time Stamp Protocol
> (TSP), (under progress). June 2000.

Are you saying that the ETSI standard is referring and possibly mandated the
use of something that is "under progress"? The lawyers should have a field
day!

Regards,
Aram Perez

---

From: "Ramsay, Ron" <[email-masked]>
Date: Mon, 24 Jul 2000 13:30:25 +1000

I don't have more specific information, but I think they saw the strength of
their method as being impervious to the compromise of a single server. You
seem to be addressing password cracking. Password cracking wou

-----Original Message-----
From: Bob Jueneman [mailto:[email-masked]]
Sent: Saturday, 22 July 2000 0:54
To: Ramsay, Ron; [email-masked]
Cc: [email-masked]
Subject: RE: Signing what you don't understand

I can't tell from the brief description, but it appears that they are using
a simple password to log on sequentially to multiple sites, and then
assembling the collected secret shares at that point.
 
Granted that this makes it impossible for a rogue administrator at one
institution to access a user's keys, but what is to prevent an attacker from
collecting the shares himself, using a multiplicity of simple passwords?
 
Even if the user is scrupulous about using a different password for each
server (making it very difficult to remember them all), the effort to break
the system would seem to be merely additive, rather than exponential.
Guessing the or four simple passwords is still simple.
 
I must be missing something.  Does anyone have the patent application, or
further details?
 
Bob

Ron.
-----Original Message-----
From: Peter Williams [ mailto:[email-masked]]
<mailto:[email-masked]]> 
Sent: Friday, 21 July 2000 12:52
To: 'Richard Levitte'; Anders Rundgren
Cc: Peter Lipp; [email-masked]; [email-masked]
Subject: RE: Signing what you don't understand

http://www.verisign.com/press/2000/roaming.html
<http://www.verisign.com/press/2000/roaming.html> 

-----Original Message-----
From: Richard Levitte [ mailto:[email-masked]]
<mailto:[email-masked]]> 
Sent: Thursday, July 20, 2000 11:24 AM
To: Anders Rundgren
Cc: Peter Lipp; [email-masked]; [email-masked]
Subject: Re: Signing what you don't understand

> http://www.arcot.com/products/webfort.html
<http://www.arcot.com/products/webfort.html>