Subject: RE: Signing what you don't understand

From: "Heimberg, Jim" <[email-masked]>
Date: Tue, 18 Jul 2000 14:43:51 -0400

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

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

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"?

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

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.

>In my mind, authentication and digital signatures are inseparable and we
>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___

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

>>ns.com.au]
>>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]>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

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

---

From: "Jean Abraham" <[email-masked]>
Date: Wed, 19 Jul 2000 08:43:29 +0300

Hi,

There is a difference actually,

When you sign the fedex package the person taking your signature doesnot
know if its who you say you are. But in the case of a digital certificate
only you can sign a email and from YOUR OWN computer which YOU ONLY have
access for.

Regarding the fooling of the CA, when a CA is created it is a trusted third
party that creates it (trusted by the world).  And if it is not a trusted
third party then you have the option to accept or decline opening the email
or trusting the email.

Jean

Key Manager
Arabtrust
Kuwait

[email-masked]

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

differences.

___tony___

the

was
if
It
but
the
intent
A
key
using
unless
different
the
that
being
to
position
commercial
involvement

---

From: Paul Koning <[email-masked]>
Date: Wed, 19 Jul 2000 09:26:50 -0400 (EDT)

>>>>> "Jean" == Jean Abraham <[email-masked]> writes:

 Jean> Hi, There is a difference actually,

 Jean> When you sign the fedex package the person taking your
 Jean> signature doesnot know if its who you say you are. But in the
 Jean> case of a digital certificate only you can sign a email and
 Jean> from YOUR OWN computer which YOU ONLY have access for.

If the computer is a PC running the most popular PC operating systems,
that statement is extremely optimistic at best.

So long as security remains a non-goal of such operating systems,
digital signatures produduced by such systems will not offer any
meaningful guarantees of any kind.

	   paul

---

From: "Jean Abraham" <[email-masked]>
Date: Wed, 19 Jul 2000 16:32:20 +0300

Digital signatures generation or creation is not based on the O/S of a
particular PC but on the software that is used to generate it.  The most
important apsect in a digital certificate(which is used to create a digital
signature - end user) is that the private key is always with the owner and
never in transist.  And the private key of the CA that signs the end-user
certs are NEVER in transist, therefore the authenticity of the certificate
is good and compromise of the end-user certificate ia void only from the PC
it would be installed on.

Jean

-----Original Message-----
From: Paul Koning [mailto:[email-masked]]
Sent: Wednesday, July 19, 2000 4:27 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: Signing what you don't understand

	   paul

---

From: Paul Koning <[email-masked]>
Date: Wed, 19 Jul 2000 09:53:10 -0400 (EDT)

>>>>> "Jean" == Jean Abraham <[email-masked]> writes:

 Jean> Digital signatures generation or creation is not based on the
 Jean> O/S of a particular PC but on the software that is used to
 Jean> generate it.  The most important apsect in a digital
 Jean> certificate(which is used to create a digital signature - end
 Jean> user) is that the private key is always with the owner and
 Jean> never in transist. 

You're entirely missing the issue that started this long string of
notes. 

First of all, the private key is "always with the owner" *only* if you
have a smartcard with embedded PKI engine.  Those exist but there
certainly are plenty of PK signing scenarios where they are not used.

Second, and this is what started things, the data being signed (hash
or whatever) are supplied to the signing engine by application
software.  If the application is subverted (easy to do with a number
of very popular applications) OR the underlying OS is subverted, an
attacker can supply different data to be signed from what you thought
you were signing.

So the OS is absolutely part of the puzzle; it is not sufficient to
consider only "the software that is used to generate [the
signature]".  The application may well be the weakest link, of course;
certainly in a number of well-known cases the application is indeed
the open barn door through which the viruses enter.  But it is by no
means the only possible barn door.

       paul

---

From: "Jean Abraham" <[email-masked]>
Date: Wed, 19 Jul 2000 17:03:06 +0300

Paul,

Private keys are also embeded in the browser as well as on a Luna Token.

MD5 or hash.... are algorithms that generate the public key and private key
and also used for encryption purposes.  Now if a application has to be
subverted it can only be done with the operators knowledge or the creator of
the application.  Regarding the virus,  a virus cannot attack a private key.
The virus creator needs to know the algorithm of the private key or the
public key which will enable the virus to act.  Which is why any CA that
generates end-user certificates are generated or created with utmost
security in mind.

I hope that clears everything

Jean

-----Original Message-----
From: Paul Koning [mailto:[email-masked]]
Sent: Wednesday, July 19, 2000 4:53 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: Signing what you don't understand

       paul

---

From: Dennis Glatting <[email-masked]>
Date: Wed, 19 Jul 2000 08:49:12 -0700

Paul Koning wrote:
	[snip]
> meaningful guarantees of any kind.

And anything derived from biometrics on said operating system.

---

From: Dennis Glatting <[email-masked]>
Date: Wed, 19 Jul 2000 08:57:55 -0700

>  Jean> user) is that the private key is always with the owner and

I came into this conversation late so I apologize if this has been
mentioned before. The following URL is an interesting read on this
topic, in particular Risk #2.
	http://www.counterpane.com/pki-risks.html

---

From: Dennis Glatting <[email-masked]>
Date: Wed, 19 Jul 2000 09:26:00 -0700

> generates end-user certificates are generated or created with utmost

This is not true. 

Public and private keys are often stored in well known places. All a
virus needs to do is copy those files and send them to a remote
source. There are plenty of examples of viruses doing this. On
Microsoft OS platforms unauthenticated ActiveX controls can be
executed and a virus can execute simply by being received
(http://www.sans.org/newlook/resources/win_flaw.htm). If one is stupid
enough to publicly share on the Internet part of drive where the keys
are located then the keys can be remotly copied (e.g.,
http://www.latimes.com/business/updates/lat_scour000714.htm),
attacked, and exploited.

Regarding my previous message about PKI risks, the paper by Schneier
and Ellison is reasonably current and forceful; however, there are
others. I remember seeing a paper by Don Davis dated 1996 (I believe)
saying similar things (sorry, my memory is foggy and I lost the URL).

-- 
Dennis Glatting
Copyright (c) 2000 Software Munitions

---

From: Ben Laurie <[email-masked]>
Date: Wed, 19 Jul 2000 18:53:00 +0100

> certainly are plenty of PK signing scenarios where they are not used.

Woah! Smartcard salesman detected... what about, say, a Palm, or a
Psion? These have an advantage over smartcards, too, in that they have
UIs. Smartcards are a technology whose time never really arrived, and is
rapidly passing. IMO.

Cheers,

Ben.

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

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

---

From: Ben Laurie <[email-masked]>
Date: Wed, 19 Jul 2000 18:56:32 +0100

Jean Abraham wrote:
> and also used for encryption purposes.

Errr ... no they aren't.

>  Now if a application has to be
> public key which will enable the virus to act.

Which is public knowledge.

>  Which is why any CA that

CAs do not generate private keys, except their own.

Cheers,

Ben.

---

From: "Stefan Kelm" <[email-masked]>
Date: Wed, 19 Jul 2000 20:56:17 +0200

> UIs. Smartcards are a technology whose time never really arrived, and is

Regarding PDAs I recommend the following research paper and the
web site mentioned on the following URL:

"Hand-Held Computers Can Be Better Smart Cards"
Dirk Balfanz, Ed Felten. Proceedings of USENIX Security '99, August, 1999.
http://www.cs.princeton.edu/sip/pub/pilotkey.php3

Cheers,

	Stefan.

--------------------------------------------------------
PKI-Symposium, 10.-11.Oktober 2000, www.pki-symposium.de
--------------------------------------------------------
Dipl.-Inform. Stefan Kelm
Security Consultant

Secorvo Security Consulting GmbH
Albert-Nestler-Strasse 9, D-76131 Karlsruhe

Tel. +49 721 6105-461, Fax +49 721 6105-455
E-Mail [email-masked], http://www.secorvo.de
-------------------------------------------------------
PGP Fingerprint 87AE E858 CCBC C3A2 E633 D139 B0D9 212B

---

From: Eric Murray <[email-masked]>
Date: Wed, 19 Jul 2000 20:25:12 -0700

On Wed, Jul 19, 2000 at 06:53:00PM +0100, Ben Laurie wrote:
> UIs.

The UI on a Palm is really useful from a security standpoint.  However,
the OS with no memory protection negates any use that requires security.
The slow crypto performance doesn't help either.

The ideal token for carrying private keys and digitally signing
documents would be something with a display (like a Palm) and an OS like
a smartcard's that protects the different applications and their keys
from each other.

Unfortunately that display costs a lot.  The CPU power to render anything
interesting on it the display, and to do crypto in reasonable speed adds
to the price.  With a readable display (but not pressure-sensitive
like a Palm), probably 5-10x a high-end smartcard.

> Smartcards are a technology whose time never really arrived, and is
> rapidly passing. IMO.

The problem isn't that they're not being used, it's that they've
never come close to matching the hype, and they probably won't ever.

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

---

From: "Jean Abraham" <[email-masked]>
Date: Thu, 20 Jul 2000 08:41:51 +0300

Yes, CA's dont create private keys except their own
I meant to say that a CA signs a end-user certificate.

When you apply for a certificate to sign and encrypt an email through a
browser then the private key is embeded in the browser and a entry is made
in the registry.

Jean

-----Original Message-----
From: Ben Laurie [mailto:[email-masked]]
Sent: Wednesday, July 19, 2000 8:57 PM
To: Jean Abraham
Cc: Paul Koning; [email-masked]
Subject: Re: Signing what you don't understand

Errr ... no they aren't.

Cheers,

Ben.

---

From: Ben Laurie <[email-masked]>
Date: Thu, 20 Jul 2000 09:36:49 +0100

> The slow crypto performance doesn't help either.

I'm not arguing with that - but how about the newer PC-style PDAs
(haven't got around to finding out what's in them, but an MMU seems
likely)?

> a smartcard's that protects the different applications and their keys

EROS!!!

> like a Palm), probably 5-10x a high-end smartcard.

See below.

> never come close to matching the hype, and they probably won't ever.

Quite. Whereas PDAs are everywhere.

Cheers,

Ben.

---

From: "Piers Chivers" <[email-masked]>
Date: Thu, 20 Jul 2000 09:48:23 +0100

Jean,
I disagree with your comment that the "most important apsect...is that the
private key is always with the owner and never in transist" (I think you
meant transit).

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?

I would argue that the important point is that the key and user are
"strongly-bound".  The system should ensure that the key is only useable by
the intended end-user.  The physical location of the key is irrelevant.
Indeed, it could be located thousand of miles away over the Internet.

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.

Thanks,
Piers

-----Original Message-----
From: Jean Abraham [mailto:[email-masked]]
Sent: 19 July 2000 14:32
To: Paul Koning
Cc: [email-masked]
Subject: RE: Signing what you don't understand

Jean

-----Original Message-----
From: Paul Koning [mailto:[email-masked]]
Sent: Wednesday, July 19, 2000 4:27 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: Signing what you don't understand

	   paul

------------------------------------------------------------------------------------------
This message is for the named persons use only.  It may contain confidential, proprietary or legally privileged information.  No confidentiality or privilege is waived or lost by any mistransmission.  If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender.  You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. PROTEK Network Management Group and each of its subsidiaries reserve the right to monitor all e-mail communications through its networks.  Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity.

---

From: "Jean Abraham" <[email-masked]>
Date: Thu, 20 Jul 2000 12:33:31 +0300

Piers,

If you would take in to consideration certs that sign emails only then the
private key is in the browser or in the machine from which the cert was
requested for.  When you speak of web server certs then the private key is
with the client's web server.  If a private key is not with the owner then
the owner cannot encrypt or sign or open any email that has been previously
signed.  At runtime you are speaking of is online shopping then you would
have https:// which is SSL then no private key downloaded to someone's PC.

You can test the above by applying for a cert that signs email, then before
installation of the cert reformat the system and you will see that the cert
will not install.  For the web server cert you can test, before installation
of the cert reconfigure the web server or format the system.

The phyical location of the private key is relevant because with that anyone
can decrypt any messages encrypted by the persons public key by getting hold
of the private key. But the phyiscal location of the public key is
irrelevant.

Validity of the signatures have nothing to do with the private key and
end-user.  It should be validity of certs rather than signatures.  A cert
signs and encrypts a particular information.

Jean

-----Original Message-----
From: Piers Chivers [mailto:[email-masked]]
Sent: Thursday, July 20, 2000 11:48 AM
To: 'Jean Abraham'; 'Paul Koning'
Cc: [email-masked]
Subject: RE: Signing what you don't understand

Jean,

Thanks,
Piers

-----Original Message-----
From: Jean Abraham [mailto:[email-masked]]
Sent: 19 July 2000 14:32
To: Paul Koning
Cc: [email-masked]
Subject: RE: Signing what you don't understand

Jean

-----Original Message-----
From: Paul Koning [mailto:[email-masked]]
Sent: Wednesday, July 19, 2000 4:27 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: Signing what you don't understand

	   paul

----------------------------------------------------------------------------
--------------
This message is for the named persons use only.  It may contain
confidential, proprietary or legally privileged information.  No
confidentiality or privilege is waived or lost by any mistransmission.  If
you receive this message in error, please immediately delete it and all
copies of it from your system, destroy any hard copies of it and notify the
sender.  You must not, directly or indirectly, use, disclose, distribute,
print, or copy any part of this message if you are not the intended
recipient. PROTEK Network Management Group and each of its subsidiaries
reserve the right to monitor all e-mail communications through its networks.
Any views expressed in this message are those of the individual sender,
except where the message states otherwise and the sender is authorised to
state them to be the views of any such entity.

---

From: Paul Koning <[email-masked]>
Date: Thu, 20 Jul 2000 09:17:02 -0400 (EDT)

>>>>> "Ben" == Ben Laurie <[email-masked]> writes:

 Ben> Eric Murray wrote:
 >>  On Wed, Jul 19, 2000 at 06:53:00PM +0100, Ben Laurie wrote: >
 >> Paul Koning wrote: > > > > First of all, the private key is
 >> "always with the owner" *only* if you > > have a smartcard with
 >> embedded PKI engine.  Those exist but there > > certainly are
 >> plenty of PK signing scenarios where they are not used.  > > Woah!
 >> Smartcard salesman detected... what about, say, a Palm, or a >
 >> Psion? These have an advantage over smartcards, too, in that they
 >> have > UIs.
 >> 
 >> The UI on a Palm is really useful from a security standpoint.
 >> However, the OS with no memory protection negates any use that
 >> requires security.  The slow crypto performance doesn't help
 >> either.

 Ben> I'm not arguing with that - but how about the newer PC-style
 Ben> PDAs (haven't got around to finding out what's in them, but an
 Ben> MMU seems likely)?

If the applications are well-controlled the lack of MMU doesn't
matter.  I could point you to several examples of secure timesharing
systems built on top of apparently-insecure hardware.

Conversely, PC-style PDAs run PC-style applications and a PC-style OS,
and therefore are likely to be just as virus-friendly as the PCs are.

It's easy to build insecure products on any hardware, if your design
rule is to aim for flashy "features" and use those as a justification
for designing security chasms into the product.

The interesting question is where the Palm OS fits in this scale.  I
don't know from personal analysis.  I'd expect it to be somewhere in
the middle, though how far to the insecure side is the critical
question. 

    paul

---

From: "Peter Lipp" <[email-masked]>
Date: Thu, 20 Jul 2000 17:58:35 +0200

> browser.  Are you saying that signatures created using these keys are
Are you sure? Could you provide a reference? I doubt that strongly...

Peter

---

From: "Piers Chivers" <[email-masked]>
Date: Thu, 20 Jul 2000 19:19:04 +0100

Entrust TruePass

Baltimore did something similar for a UK bank.  I don't think it's
commercially available but was presented at Infosec 2000. Maybe someone from
Baltimore can expand??

Piers

-----Original Message-----
From: Peter Lipp [mailto:[email-masked]]
Sent: 20 July 2000 16:59
To: [email-masked]
Cc: [email-masked]
Subject: AW: Signing what you don't understand

Peter

---

From: Venkateswara Reddy A <[email-masked]>
Date: Tue, 25 Jul 2000 13:06:47 +0530

> and also used for encryption purposes.

MD5 or hash algos generate public key and private key. huh

absolutely wrong stmt

regards
Venkat