Certificate proposal

-----BEGIN PGP SIGNED MESSAGE-----

X.509 certificates are not totally bad.  Their structure contains lessons
for anyone designing a certificate structure.  [Raw X.509 does not imply a
hierarchy, I believe.  Steve Kent & Co. do.]

However, there are also some serious problems with X.509 certs, aside from
their use of ASN.1.

Perhaps the biggest problem is the use of a name -- a text string (or some
abortion like the DN which can be reduced to a text string) -- as the
anchor point.

This anchor point needs to be unique.  Since it is just a text string, that
means that the certificate authority needs to guarantee uniqueness.
However, it is also supposed to stand for a unique individual.  Since it is
not that individual's DNA sequence -- it is not testable.  There has to be
machinery set up outside the certificate definition for binding this text
string to its individual.

		------------------------------

PGP certificates have the same problem.  In that case, it is an e-mail
address and name (by tradition) as the text string.  That needs to be bound
to some physical body.  If it is an e-mail name, there is some binding
enforced by whatever access mechanisms protect access to that e-mail
account.  However, that binding is weak and also outside the certificate
definition.

		------------------------------

Let me propose an alternative unique name: the public key (or a good hash
of it).  The public key has an advantage over both X.509 and PGP names.
The binding between it and its human being is testable.  You can challenge
the human in question to sign something.



Assuming you use a public key as the unique name, you end up with a much
simplified certificate.  In fact, the notion of "certificate" may go away,
in the sense that the certificate binds a key to a person through a unique
name.  The person binds himself to his key, on challenge (or on any message
signature).

What remains is a need for attributes to be bound to a key.  For example,
someone might testify that E0414C79B5AF36750217BC1A57386478 has brown hair,
is balding and wears a pony tail, by signing a message to that effect.
Someone else might sign a message stating that the person who owns the
private key of 61E2DE7FCB9D7984E9C8048BA63221A2 is authorized to spend
money from bank account number 07123 of Provident Savings in Columbia MD.
That latter signator needs to be verified as authorized to make such an
assertion -- and you end up with a certification chain -- but it is not
hierarchical like X.509 and it is not web-of-trust -- it is relational.  It
is not a chain binding key to person but key's person to attribute or
permission.  It goes directly to what we need to accomplish without the
middleman -- without stopping at a person in the middle.

I realize that if you want to revoke a key, then it might help to have
bindings be to something other than the key.  That way, you can change keys
out from under the binding.  However, every method I've examined for
accomplishing that has security weaknesses.  The best method I've found yet
has a very long signature key -- used only rarely (e.g., when acquiring an
attribute-certificate worth a great deal; and signing more transient keys) --
and never normally revoked (or, if revoked, causing a widespread
re-establishment of bindings -- like when you lose your wallet today).

		------------------------------

Current certificates are going down a fundamentally wrong path.  They are
trying to bind keys to people and let Society somehow bind attributes to
people -- but the latter binding is too weak to permit keys to be bound to
attributes or permissions.

The community will discover this, soon, but the farther we play along the
X.509 path (especially, but also the PGP path), the more inertia there will
be to overcome in trying to fix this problem.  I would therefore suggest
that the PGP development process address this issue now and continue the
established habit of taking the lead into sanity.

 - Carl

+--------------------------------------------------------------------------+
|Carl M. Ellison    cme@acm.org    http://www.clark.net/pub/cme		   |
|PGP: E0414C79B5AF36750217BC1A57386478 & 61E2DE7FCB9D7984E9C8048BA63221A2  |
|  ``Officer, officer, arrest that man!  He's whistling a dirty song.''    |
+---------------------------------------------- Jean Ellison (aka Mother) -+

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMHAK8FQXJENzYr45AQFsdAP+JswAq/H4JIDE3+VlMsi87PBPCNBA7jg7
0ftkd8v7vrSSNda5aF+HVB7oKHylA/Lb90bvjMK7CKOJJ7aTzRP9IsAiz1i48FAR
LAeD59v5SAKmAhaTMMYSRyKFRRXEaqIdEoJW3XKQBJ57b8R38vWKjR/11eTtCKjV
joH4c5hhWmY=
=ayYh
-----END PGP SIGNATURE-----

Hal wrote:
> 
> tomw@orac.engr.sgi.com (Tom Weinstein) writes:
> 
> >In article <DG06FE.IA8@sgi.sgi.com>, Hal <hfinney@shell.portal.com> writes:
> 
> >> OK, so suppose I want to send my credit card number to Egghead Software.
> >> I get one of these new-fangled certificates from somebody, in which
> >> VeriSign has certified that key 0x12345678 has hash 0x54321.  I think we
> >> can agree that by itself this is not useful.  So, it will also bind in
> >> some attribute.  What will that attribute be?
> 
> >Um, just a wild guess, but... your credit card number maybe?  (Well,
> >okay, its hash.)
> 
> I may not have been clear: the certificate I was referring to was the one
> from Egghead, the one which I will use to make sure that I have a valid
> key for Egghead.  Such a certificate would of course not have my credit
> card number; it would probably have some information related to Egghead.
> My rhetorical point was that information would most plausibly be a NAME
> by which I would refer to Egghead.  I am still trying to understand how
> these proposals to take names out of the picture will apply to a
> commonplace situation like this one.

  I don't think that we need to get rid of names entirely.  It all
depends on the intended use.  In this case it would be reasonable
for the certificate to have the name in it.  It would also probably
be signed by a bank or card association CA, which was set up
specificly to sign merchant certificates.

	--Jeff

-- 
Jeff Weinstein - Electronic Munitions Specialist
Netscape Communication Corporation
jsw@netscape.com - http://home.netscape.com/people/jsw
Any opinions expressed above are mine.

In article <DG0EzA.Gs5@sgi.sgi.com>, Hal <hfinney@shell.portal.com> writes:
> tomw@orac.engr.sgi.com (Tom Weinstein) writes:

>> Um, just a wild guess, but... your credit card number maybe?  (Well,
>> okay, its hash.)

> I may not have been clear: the certificate I was referring to was the one
> from Egghead, the one which I will use to make sure that I have a valid
> key for Egghead.  Such a certificate would of course not have my credit
> card number; it would probably have some information related to Egghead.
> My rhetorical point was that information would most plausibly be a NAME
> by which I would refer to Egghead.  I am still trying to understand how
> these proposals to take names out of the picture will apply to a
> commonplace situation like this one.

Yes, it seems I misunderstood you.  There would have to be some binding
between the key of the merchant and some identifying information that
would allow the user to verify the merchant's identity.  This could take
the form of a True Name for the merchant and a trusted CA.  Another
approach would take the form of an FQDN, an IP address and a trusted CA.
In this case the software would have to verify that the FQDN and IP
address match the URL and DNS lookup, respectively.  Unfortunately, this
also requires that any time the IP address changes that the merchant get
a new certificate.  Also, the CA must be checked to verify that the
certificate hasn't been revoked, or you run the risk of an attacker
getting the old IP address.

Does anyone see any other options?

-- 
Sure we spend a lot of money, but that doesn't mean    |  Tom Weinstein
we *do* anything.  --  Washington DC motto             |  tomw@engr.sgi.com

PGP message

-----BEGIN PGP SIGNED MESSAGE-----

>From: Raph Levien <raph@CS.Berkeley.EDU>
>Date: Mon, 02 Oct 1995 10:13:08 -0700

>I am extremely glad to hear Carl propose this. Let me propose something
>just a bit more concrete (Carl might not like it because it contains just
>a hint of ASN.1, but what the hell).

I'll hold my nose while reading :-).

>I propose that the unique name be the MD5 hash of the MOSS public key, as
>formatted according to the MOSS specification (ASCII and all). PGP keys
>can easily be converted into MOSS ones, so it's pretty easy. The hash
>should be expressed as 32 hex digits, so that it can easily be typed in
>or spoken. The only ambiguity in this proposal is where to put the
>newlines, if any. For concreteness, I propose that there be no newlines
>in the public key value.

I see no problem using a hash.  I might use SHA rather than MD5.  MD5 is a
wee bit too short.  But, for what we're doing, MD5 is just fine -- and as a
hash of a public key, the cost of finding alternatives is high enough that
MD5's shortness probably isn't a problem.

However, why convert PGP keys to MOSS and then hash?  Hash the PGP key
straight.

You're right that my proposal was not concrete at all.  To make it
concrete, you'd want to specify the signed message which takes the place of
a certificate.  I tried this once before, roughly, but I never gave it the
effort it deserves.

Let me call this non-certificate a blurk (waiting for a real name).

		------------------------------

For example, you need to identify:

the signee (a public key or hash of a key)
	the public key needs to be identified as to type (RSA, D-H, DSA, ...)
	and the package using it can also be identified (e.g., PGP, MOSS, ...)

the signer (a public key or hash of a key -- as used in the blurk which
	grants authority to the signer)

a text string (or paragraph) giving the attribute being attested to --
	and possibly giving validity dates, etc.

the signature (in some algorithm)  [You might want to allow for multiple
	signatures in different algorithms and/or different packages
	-- to keep the signee from having to send out dozens of blurks
	or storing dozens in a database.]

		------------------------------

The entire thing could be a signed cleartext message:

	signer's key; [signee's key; text] signature (of [])

Alternatively, you could modify the PGP UserID field (or make something
very similar) with raw text (not treated as an ID on the key) and a sig on
the text and signed key.

Signing a cleartext message has some appeal.

As for how this would be used -- my guess from looking at X.509 is that
it's meant for machine parsing and understanding (although I know of no
programs which follow them beyond sig checking).  A cleartext signed
message requires human reading and filing.  However, that's fine.  After
all, it is a human who decides whether to act or not.

If there is a computer deciding whether to act based on the blurk, the
signed text could include SMTP-style tagged text lines for the program to
go find.

Looking forward to more concrete elaborations....

 - Carl

+--------------------------------------------------------------------------+
|Carl M. Ellison      cme@tis.com    http://www.clark.net/pub/cme	   |
|Trusted Information Systems, Inc.   http://www.tis.com/                   |
|3060 Washington Road          PGP 2.6.2:  61E2DE7FCB9D7984E9C8048BA63221A2|
|Glenwood MD  21738         Tel:(301)854-6889      FAX:(301)854-5363       |
+--------------------------------------------------------------------------+

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMHBgrVQXJENzYr45AQG7wgP+MzX/uQsIw5G4YjaRFzPFGV1z6MV5RV5g
xvH6/wv6XLyeZ3DTn/akiwiFO5nl8aSUEq5F7huMByiYctXjlI/05l5KFUxpjNY5
QpQH8hRAIO8PnrItyK0Fg3uFbDzfloSuhhCoJIFlrkAxEXj1CoMKWkN6hlEz1jmy
fY2ceAz6KPo=
=Jdrm
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----

(...WAY behind in cypherpunks mail...)

Carl Ellison <cme@TIS.COM> writes:
>Let me propose an alternative unique name: the public key (or a good hash
>of it).  The public key has an advantage over both X.509 and PGP names.
>The binding between it and its human being is testable.  You can challenge
>the human in question to sign something.

I don't understand this whole discussion.  A certificate is a signed
binding of a key and a unique name, right?  If the proposal here is
that the unique name be a hash of the key, you are suggesting a signed
binding of a key with its hash!  What is the point of a certificate
which binds a key to its hash?  What is such a certificate asserting?
It seems to be saying nothing at all.  Anybody can already tell if a
hash is right, for all the good that does you.  It's like a notarized
statement that 2+2=4.  I don't see the point.  As Carl goes on to say:

>Assuming you use a public key as the unique name, you end up with a much
>simplified certificate.  In fact, the notion of "certificate" may go away,
>in the sense that the certificate binds a key to a person through a unique
>name.  The person binds himself to his key, on challenge (or on any message
>signature).

If in fact this is just a suggestion that we not have certificates, that
may have some value.  But as a literal suggestion that certificates bind
a key hash to a key, that just doesn't make sense to me.

The thing to keep in mind is, why do we want certificates?  Why not just
use unsigned keys?  If I encrypt a message for Carl based on some key I
found lying around somewhere which someone told me is his, and I send it
to his mailbox, and I get a reply back, how secure is that?  We all know
that you don't get the full security of the encryption if you do this.
Man in the middle attacks might not be easy to do in such a situation but
they are certainly possible.  It is such attacks that certificates (including
PGP key signatures) are designed to prevent.

I'd like to see some grounding of this discussion in terms of the role of
certificates, and ways to prevent man in the middle attacks.  I certainly
have no love for facist worldwide ID cards and hierarchical, organization
based naming schemes, but just using any old key because it seems to work
OK most of the time isn't going to fly IMO.

Hal

-----BEGIN PGP SIGNATURE-----
Version: 2.6

iQBVAwUBMHQw5BnMLJtOy9MBAQEDFQIAxvq8EC5zBMvUYGjwMUb2LDy/kt0gP19Z
S8BY+fxswuQCIqyet6WqddtVNyBE6QlO7XTTOX5RtZvMLHLN0YVp3A==
=Bq7+
-----END PGP SIGNATURE-----

I strongly support what Carl Ellison is saying. I've been meaning to write
up something on it for so long that I must accept I'll never do it. So
here instead is a quick example.

 > I don't understand this whole discussion.

The idea is to make the public key the centre of the architecture instead
of being an attribute of some other centre (e.g. distinguished name).

Consider the IPSEC case. The current situation is:

1. We go through some process, let's call it Process A, where we determine
   that we want to talk to IP address 192.9.8.7.

2. We go through another process where we obtain the public key of 192.9.8.7.

3. We then try to decide, based on one or more certificates, whether we
   trust the public key to be the correct public key for 192.9.8.7.

Now consider the key-centric version.

1. Process A returns a public key which denotes the destination we want to
   talk to.

2. We then go through a process to obtain the IP address that belongs to
   that public key. We probably won't use the public key as an index to
   get that information. We probably use the information that was input
   to Process A. In fact this information may fall out as a byproduct
   of Process A. [However if we needed to make a scalable distributed
   database of RSA public keys then I have a design to do this -
   available on application.]

3. We don't need to trust any certificates or anything else at this stage.
   The fact that the IP address belongs to the Public Key is signed by
   the Public Key itself.

The same thing happens with e-mail. If "Process A" gives us an e-mail
address to send to then we worry about whether we have the right public
key to go with it. If Process A gives us a Public Key then we can
have certainty about the associated e-mail address because the association
is signed by the Public Key.

And a big win that just falls out of this is that I can have a
continuous exchange of information with one IP destination even if
it keeps changing its actual IP address (mobile computing) or I
can have an e-mail conversation with a person who keeps changing
their e-mail address. The things you want just fall out instead of
requiring clever software solutions.

 >  A certificate is a signed
 > binding of a key and a unique name, right? 

In the key-centric world a certificate binds some attribute as a property
of a publc key. So an X.509 certificate would say "The owner of this
public key [i.e. person who knows the corresponding private key] owns
the following point in the X.500 namespace", rather than that "the
person identified by this DN owns the following publc key". Experience
has shown that the latter interpretation is a mine-field. It really
doesn't work.

The idea of a key-centric architecture is the proverbial "idea whose time
has come". There are echoes of it in MOSS and in STT. But it really calls
out for a group to work out a complete architecture. If someone wants to
start such a discussion I'll make sure I make time to be part of the process.

Bob Smart

Hal wrote:
> The thing to keep in mind is, why do we want certificates?  Why not just
> use unsigned keys?  If I encrypt a message for Carl based on some key I
> found lying around somewhere which someone told me is his, and I send it
> to his mailbox, and I get a reply back, how secure is that?  We all know
> that you don't get the full security of the encryption if you do this.
> Man in the middle attacks might not be easy to do in such a situation but
> they are certainly possible.  It is such attacks that certificates (including
> PGP key signatures) are designed to prevent.

I think Carl's point is that when you write an e-mail to Carl, you 
probably don't care that it reaches the "real" Carl Ellison, because you 
don't have a binding between the name "Carl Ellison" and the physical 
person.  A binding between a name and a key is useless if there is no 
binding between the name and the person.  Since this is the case, why not 
forget about the binding between the name and the key (or turn it into a 
local one as I suggested in the previous post) and go straight to the 
binding between the key and the person?

On the other hand, if you do have a binding between the name and the 
person, then most likely you met Carl at some point in the past and he 
told you his name was Carl Elison.  In that case it would have been just 
as easy for him to give you his public key instead.

Wei Dai

Hal wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> 
> (...WAY behind in cypherpunks mail...)
> 
> Carl Ellison <cme@TIS.COM> writes:
> >Let me propose an alternative unique name: the public key (or a good hash
> >of it).  The public key has an advantage over both X.509 and PGP names.
> >The binding between it and its human being is testable.  You can challenge
> >the human in question to sign something.
> 
> I don't understand this whole discussion.  A certificate is a signed
> binding of a key and a unique name, right?  If the proposal here is
> that the unique name be a hash of the key, you are suggesting a signed
> binding of a key with its hash!  What is the point of a certificate
> which binds a key to its hash?  What is such a certificate asserting?
> It seems to be saying nothing at all.  Anybody can already tell if a
> hash is right, for all the good that does you.  It's like a notarized
> statement that 2+2=4.  I don't see the point.  As Carl goes on to say:
> 
> >Assuming you use a public key as the unique name, you end up with a much
> >simplified certificate.  In fact, the notion of "certificate" may go away,
> >in the sense that the certificate binds a key to a person through a unique
> >name.  The person binds himself to his key, on challenge (or on any message
> >signature).
> 
> If in fact this is just a suggestion that we not have certificates, that
> may have some value.  But as a literal suggestion that certificates bind
> a key hash to a key, that just doesn't make sense to me.
> 
> The thing to keep in mind is, why do we want certificates?  Why not just
> use unsigned keys?  If I encrypt a message for Carl based on some key I
> found lying around somewhere which someone told me is his, and I send it
> to his mailbox, and I get a reply back, how secure is that?  We all know
> that you don't get the full security of the encryption if you do this.
> Man in the middle attacks might not be easy to do in such a situation but
> they are certainly possible.  It is such attacks that certificates (including
> PGP key signatures) are designed to prevent.
> 
> I'd like to see some grounding of this discussion in terms of the role of
> certificates, and ways to prevent man in the middle attacks.  I certainly
> have no love for facist worldwide ID cards and hierarchical, organization
> based naming schemes, but just using any old key because it seems to work
> OK most of the time isn't going to fly IMO.

  I think the old idea of a certificate just binding a name and
a key is turning out to not be very useful.  That is why Netscape
Navigator 2.0 will support x509 version 3 certificates.  They allow
arbitrary attributes to be signed into a certificate.  In this new
world, you can think of a certificate as a way of binding a key with
various arbitrary attributes, one of which may be(but is not
required to be) a name.

	--Jeff

-- 
Jeff Weinstein - Electronic Munitions Specialist
Netscape Communication Corporation
jsw@netscape.com - http://home.netscape.com/people/jsw
Any opinions expressed above are mine.

Jeff Weinstein wrote:

|   I think the old idea of a certificate just binding a name and
| a key is turning out to not be very useful.  That is why Netscape
| Navigator 2.0 will support x509 version 3 certificates.  They allow
| arbitrary attributes to be signed into a certificate.  In this new
| world, you can think of a certificate as a way of binding a key with
| various arbitrary attributes, one of which may be(but is not
| required to be) a name.

	I'm a bit behind on the X.509 discussion, but does version 3
resist the attack Ross Anderson mentions in his 'Robustness Principles'
paper in Crypto '95?

	(The paper can be found in
ftp.cl.cam.ac.uk:/users/rja14/robustness.ps.Z  The wcf.ps.Z is his
'Why Cryptosystems Fail' paper, and both are well worth reading.)

Adam

-- 
"It is seldom that liberty of any kind is lost all at once."
					               -Hume

Jeff Weinstein <jsw@netscape.com> writes:
>  I think the old idea of a certificate just binding a name and
>a key is turning out to not be very useful.  That is why Netscape
>Navigator 2.0 will support x509 version 3 certificates.  They allow
>arbitrary attributes to be signed into a certificate.  In this new
>world, you can think of a certificate as a way of binding a key with
>various arbitrary attributes, one of which may be(but is not
>required to be) a name.

OK, so suppose I want to send my credit card number to Egghead Software.
I get one of these new-fangled certificates from somebody, in which
VeriSign has certified that key 0x12345678 has hash 0x54321.  I think we
can agree that by itself this is not useful.  So, it will also bind in
some attribute.  What will that attribute be?

Hal

In article <DG06FE.IA8@sgi.sgi.com>, Hal <hfinney@shell.portal.com> writes:

> OK, so suppose I want to send my credit card number to Egghead Software.
> I get one of these new-fangled certificates from somebody, in which
> VeriSign has certified that key 0x12345678 has hash 0x54321.  I think we
> can agree that by itself this is not useful.  So, it will also bind in
> some attribute.  What will that attribute be?

Um, just a wild guess, but... your credit card number maybe?  (Well,
okay, its hash.)

-- 
Sure we spend a lot of money, but that doesn't mean    |  Tom Weinstein
we *do* anything.  --  Washington DC motto             |  tomw@engr.sgi.com

Tom Weinstein wrote:
> 
> In article <DG06FE.IA8@sgi.sgi.com>, Hal <hfinney@shell.portal.com> writes:
> 
> > OK, so suppose I want to send my credit card number to Egghead Software.
> > I get one of these new-fangled certificates from somebody, in which
> > VeriSign has certified that key 0x12345678 has hash 0x54321.  I think we
> > can agree that by itself this is not useful.  So, it will also bind in
> > some attribute.  What will that attribute be?
> 
> Um, just a wild guess, but... your credit card number maybe?  (Well,
> okay, its hash.)

  The hash of just the card number isn't good enough.  If you collected
a bunch of certificates (they are public) then you could start guessing
valid card numbers and trying to match the hashes with your database.
The Mastercard SEPP proposal uses a salted hash, where the salt is
a shared secret between the bank and the user.

	--Jeff

> --
> Sure we spend a lot of money, but that doesn't mean    |  Tom Weinstein
> we *do* anything.  --  Washington DC motto             |  tomw@engr.sgi.com

  There are too many Weinsteins hanging out here lately...  :-)

-- 
Jeff Weinstein - Electronic Munitions Specialist
Netscape Communication Corporation
jsw@netscape.com - http://home.netscape.com/people/jsw
Any opinions expressed above are mine.

tomw@orac.engr.sgi.com (Tom Weinstein) writes:

>In article <DG06FE.IA8@sgi.sgi.com>, Hal <hfinney@shell.portal.com> writes:

>> OK, so suppose I want to send my credit card number to Egghead Software.
>> I get one of these new-fangled certificates from somebody, in which
>> VeriSign has certified that key 0x12345678 has hash 0x54321.  I think we
>> can agree that by itself this is not useful.  So, it will also bind in
>> some attribute.  What will that attribute be?

>Um, just a wild guess, but... your credit card number maybe?  (Well,
>okay, its hash.)

I may not have been clear: the certificate I was referring to was the one
from Egghead, the one which I will use to make sure that I have a valid
key for Egghead.  Such a certificate would of course not have my credit
card number; it would probably have some information related to Egghead.
My rhetorical point was that information would most plausibly be a NAME
by which I would refer to Egghead.  I am still trying to understand how
these proposals to take names out of the picture will apply to a
commonplace situation like this one.

Hal

-----BEGIN PGP SIGNED MESSAGE-----

Hello Hal <hfinney@shell.portal.com>
  and cypherpunks@toad.com

Hal writes:
> >In article <DG06FE.IA8@sgi.sgi.com>, Hal <hfinney@shell.portal.com> writes:
> 
> >> OK, so suppose I want to send my credit card number to Egghead Software.
...
[previous reply elided]

What you are missing is that you should not say
  "I want to send my credit card number to Egghead Software"
you should say
  "I want to send my credit card number to 12 34 56 78 9A BC DE F0"

> I may not have been clear: the certificate I was referring to was the one
> from Egghead, the one which I will use to make sure that I have a valid
> key for Egghead.  Such a certificate would of course not have my credit
> card number; it would probably have some information related to Egghead.

The certificates you'd want are:
  * informal correspondence from your friends that 12 34 56 78 9A BC DE F0
makes good widgets/gadgets/whatzits.
  * a Consumers Association report saying that 12 34 56 78 9A BC DE F0's
widgets don't have sharp edges like 13 25 36 47 58 69 7A 8B's do and
that 43 65 87 09 41 61 BA ED's are less efficient (eg "Choice" magazine).
  * possibly a certificate from the bank that 12 34 56 78 9A BC DE F0
is a merchant (if using traditional CCs).
  * or a certificate from a guarantor company saying that if
12 34 56 78 9A BC DE F0 doesn't deliver they'll return your money.

> My rhetorical point was that information would most plausibly be a NAME
> by which I would refer to Egghead.  I am still trying to understand how
> these proposals to take names out of the picture will apply to a
> commonplace situation like this one.

Yeah, I just can't imagine myself at a party introducing myself
"Hi, I'm 08 04 26 6D 01 CD AB 8A  25 A9 E2 86 AD 13 C1 BA".

Then again I never was good at parties...


To start a new sub-thread: what if the man in the middle is actually
a behaviour-modifying parasite? At that stage even a physical meeting
won't do you much good (the parasite may be otherwise asymptomatic).

It's probably more likely than having 30 FBI agents assigned to your
case...


Hope I'm making sense... (well, they say that hope dies last, no?)

Jiri
- --
If you want an answer, please mail to <jirib@cs.monash.edu.au>.
On sweeney, I may delete without reading!
PGP 463A14D5 (but it's at home so it'll take a day or two)
PGP EF0607F9 (but it's at uni so don't rely on it too much)

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2i

iQCVAwUBMHxzWSxV6mvvBgf5AQHXawP/Xls4gWUwhTFoX9w4TYaKvqbK8MF+dxgS
JPmIWdfiEijbRb/qOLzU+7NJqZ3OqcR+Ylc8uBcQPhYJgOwDSta1BYm0OrYhb+PY
6ILXeulp/2T5Y061KrbkFgJ3Z5AcsFTCBad2pHQeIzdlIixv2JPT+qbb5iEkDkgA
ebEioYxWgP0=
=pFkN
-----END PGP SIGNATURE-----

Jiri "Super Trouper" Baum writes:
> To start a new sub-thread: what if the man in the middle is actually
> a behaviour-modifying parasite? At that stage even a physical meeting
> won't do you much good (the parasite may be otherwise asymptomatic).

Descartes figured there was a benevolent God to bail him out. I believe
otherwise. But I manage to go about my business even while wallowing in a
state of Futplexian doubt.

-Futplex <futplex@pseudonym.com>

Hal wrote:
> 
> Jeff Weinstein <jsw@netscape.com> writes:
> >  I think the old idea of a certificate just binding a name and
> >a key is turning out to not be very useful.  That is why Netscape
> >Navigator 2.0 will support x509 version 3 certificates.  They allow
> >arbitrary attributes to be signed into a certificate.  In this new
> >world, you can think of a certificate as a way of binding a key with
> >various arbitrary attributes, one of which may be(but is not
> >required to be) a name.
> 
> OK, so suppose I want to send my credit card number to Egghead Software.
> I get one of these new-fangled certificates from somebody, in which
> VeriSign has certified that key 0x12345678 has hash 0x54321.  I think we
> can agree that by itself this is not useful.  So, it will also bind in
> some attribute.  What will that attribute be?

  It would be some value that would allow the credit card
authorization agency to match it up with the submitted credit
card number.  In the case of MasterCard's SEPP they are using
a salted hash of the Account Number, where the salt value is
unique per account, is secret, and is shared between the
bank and the card holder.

	--Jeff

-- 
Jeff Weinstein - Electronic Munitions Specialist
Netscape Communication Corporation
jsw@netscape.com - http://home.netscape.com/people/jsw
Any opinions expressed above are mine.