Adam Back | 14 Oct 1998 19:48
Picon

Re: proof-of-possession for DH keys


Steve Kent writes:

> Unfortunately, the possible consqquences are worse than the self-inflicted
> DoS attack you descibed.  Specifically, by having a credible CA issue a
> cert binding someone elses public key to the imposter's name, the imposter
> can claim to be the signer of traffic associated with someone else (in the
> case of a signature key bound into the certificate). 

But DH keys are not signatures keys, they are confidentiality keys.
This was the point being made: that DH POPs (see the subject line) are
not (that) useful.

The attack you describe relating to signatures keys is obviously true:
this is what self certificates protect against.  The point with a DH
key is that you can't issue a self cert, because it is not a signature
key, therefore you define a POP instead, if you want the (small)
advantage of a POP for a confidentiality key.

Adam
--

-- 
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U <at> {$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

Alan Lloyd | 1 Oct 1998 01:25
Picon

RE: NEW Data type for certificate selection ?

Sob story introduction - still on the road in the UK now - and flat chat
with the upswing in big X.500 systems and PKIs  from every point on the
compass. So the details below may have been skipped...
anyway. 

I always thought that the matching rules for certs and crls as defined
in X.509 were like other matching rules in that objects/attrs of
particular types can be searched for and managed whilst in the directory
system.

The issues is that the PKI /CA design has been designed as a set of
"sort of related objects, but operationally there are multipaths and
multi domains.. so we have an information relationship and managment
issue (in an originators domain).. and in some form, knowledge of this
"environment" must be propagated to the recipient of signed message with
a cert - so that efficient validation can occur.

The matching rule system is a mechanism for finding what one wants and
it can be configured with the desired values - ie knowledge (not
knowledge as per DSA access point knowledge) english meaning.

It strikes me that this knowledge (and the certficate)of the originating
domain should be transferred to the recipient domain and this knowledge
supplimented by the recipient - where appropriate - and this applied
through the matching rule mechanism into the directory system to achieve
validation.

the draft I submitted - draft-lloyd-dir-cert-stat  starts the
validation/matching rule direction off. And in fact permits orgainised
knowledge of validity - which is maintained by a CA..
(Continue reading)

Ed Gerck | 1 Oct 1998 05:48
Picon

Re: NEW Data type for certificate selection ?

On Thu, 1 Oct 1998, Stefan Santesson wrote:

>Ed,
>
>Thank you for very interesting input. If I may try a very compressed sum of
>your discussion it would be:
>
>1) In SSL the server may select preferred client certificate by Issuer DN,
>and "certificate type"

Stefan:

pls add in your 1) "if the server is non-anonymous"

pls add also a 0) "a self-signed common CA cert for the server and
user certs can make your life and the customer's life a lot more
pleasant"

>2) You suggest hashed SSN (social security numbers) using "salt"

if you must add SSN-based info in a public cert, IMO yes!

>
>Regarding "certificate type" I can't find this as an active selection
>mechanism. It is however mentioned as prerequisite that the certificate
>type have to match the selected key exchange algorithm.
>

I fail to see why you "can't find this as an active selection
mechanism" together with the issuer DN, even if you want to keep the
(Continue reading)

Stefan Santesson | 1 Oct 1998 09:24
Picon

Re: NEW Data type for certificate selection ?

Hi Ed,

I'm just trying to understand what you are saying.

Are what you are saying, that you would solve the problem generally by, for
each issuer, having a different Issuer DN, per certificate type? 
Well I have thought of that for the SSL/TLS case but I don't like it.
Simply because many planned CA-services does not work that way and I'm not
convinced that they should either.

The next question is, how do I use the SSL/TLS negotiation to pick the
right certificate for creating a signed object in a Java script?

/Stefan

At 12:48 AM 10/1/98 -0300, Ed Gerck wrote:
>On Thu, 1 Oct 1998, Stefan Santesson wrote:
>
>>Ed,
>>
>>Thank you for very interesting input. If I may try a very compressed sum of
>>your discussion it would be:
>>
>>1) In SSL the server may select preferred client certificate by Issuer DN,
>>and "certificate type"
>
>Stefan:
>
>pls add in your 1) "if the server is non-anonymous"
>
(Continue reading)

Anders Rundgren | 1 Oct 1998 09:07

RE: NEW Data type for certificate selection ?

Hi Ed,
>Your suggestion:
>
>The solution is to add "salt" -- like it is done in UNIX passwords.
>For example, you can add 50 chars of salt or as many as you want -- a
>passphrase. The point here is that since you know the SSN and the
>salt, no one else can guess the SSN from a dictionary attack on only
>9 digits. Better still, you can change the hash in a new cert and
>keep the SSN constant, by changing the salt, so no one can verify
>your SSN in a new cert without your cooperation.

As my countryman Stefan already pointed out we can argue for centuries about the
use of SSNs or as I would call them: PPIT - Persistent Personal Identity Tag.

Assuming that you *actually* *have* *such* *a* *scheme* you loose all the benefits of
PPITs by applying your "salted" methods to PPITs.  PPITs are not only designed to
make big-brothers job easier :-), but to allow users to authenticate themselves
using a valid certificate (be it electronical or physical) where the certificate
receiver only must know what issuers (and domain) to trust.  This is a major benefit for
all parties as you can have a life-time password/userid replacement with
full security (technically speaking) independent on actual certificate.  It simply
cuts costs and confusion (at the expense of personal integrity).   If this is
good or not is something the market (and in some cases national laws)
will decide. My personal opinion is that if successful PKIs (Stefan!) are
established based on PPITs the disbeliveers *may* change their mind.

The general-purpose browser solution is as follows:

The authenticating server may surely *suggest* a list of possible certificate types
that it may accept because it is always *you* (the user) that should manually
(Continue reading)

Olle E. Johansson | 1 Oct 1998 09:16
Picon
Favicon

Re: NEW Data type for certificate selection ?

Stefan Santesson wrote:

> 1) In SSL the server may select preferred client certificate by Issuer DN,
> and "certificate type"
> 2) You suggest hashed SSN (social security numbers) using "salt"
> 
Even if I don't know all the details in your scheme, I would like to put
up a privacy warning here. A user might not want _any_ server to search
the database of user certificates. The user might have certificates he
doesn't want a server, or rather the company running the server, to know
about. 

It's like cookies...

Regards,
Olle

--

-- 
Olle E. Johansson, oej <at> webway.se
Mobile +46 70 593 68 51, phone +46 8 590 722 40, fax +46 8 590 759 80
WebWay AB, Sweden, http://www.webway.se

Andreas Berger | 1 Oct 1998 14:52
Picon

Re: NEW Data type for certificate selection ?

Is the problem of selecting certificates somewhat similar to the
selection of telephone numbers?

Example:

have an application select a FAX number for my home phone from an
address book entry. The numbers itself (the certificate) cannot be
distinguished from other numbers, it is the attribute name "FAX, home"
(or something like this) that shows the designated use of the number.

A little difference exists, in that certificates usually contain some
information about the intended use. But this information is not encoded
in a uniform way. The decision is usually left to the application (which
is the problem to be solved here?).

Andreas
--

-- 
Fifty-three percent of Fortune 1000 executives think the
Arch Deluxe is something that helps to run a computer.
-- Jericho Communications

Stefan Santesson | 1 Oct 1998 14:56
Picon

Re: NEW Data type for certificate selection ?

There are similarities with phone numbers, but an even better example is to
compare with plastic cards in your wallet.

Say that every plastic card is a certificate given to you to be used in a
certain context. When you by gas you use your petrol card, when you borrow
books you use your library card.

The service context determines which certificate (plastic) you are using.

In a computer environment this is the same. Depending on the service
context you will use different certificates and different private keys for
signatures and decryption.

To day there is no "good" way to communicate the "service context" to the
certificate selecting function in the client. What is proposed here is that
we define a mechanism for this so that a context aware server may help the
client to select a suitable certificate.

This is relevant for a wide range of application and service levels, from
communication services (SSL/TLS) up to application levels (S/MIME and Java
scripts). But regardless of implementation level a general data type could
be used to specify the certificate match rule. X.509 have defined 2
relevant match rules. certificateMatch and certificateExactMatch.

So all we basically have to do is to convince the TLS, S/MIME and Java
peoples to include this in their protocols and client-server products.

/Stefan

At 01:52 PM 10/1/98 +0100, Andreas Berger wrote:
(Continue reading)

Paul Koning | 1 Oct 1998 15:11

Re: NEW Data type for certificate selection ?

>>>>> "Ed" == Ed Gerck <egerck <at> laser.cps.softex.br> writes:

 Ed> On Thu, 1 Oct 1998, Stefan Santesson wrote:
 >>...
 >> You and I can argue for centuries if certificates handled in
 >> browsers should, or should not, be allowed to contain SSN.

 Ed> No, I don't argue. As I wrote two msgs ago, some think they have
 Ed> valid reasons for it and I do not disagree with the need to
 Ed> preserve freedom.

Unfortunately, the world (or at least the country) is infested with
organizations that think they have a valid reason to ask for a SSN
when in fact they have neither a valid reason nor any legal authority
to do so.  Some, if you pound on the table enough, will yield.  (For
example, my medical insurance started by asking for it, but when
pushed conceded that they could make up a number instead.  Surprised
me; most outfits of that type don't have enough sense to see that.)

So I would say that anything protocol mechanism that encourages this
sort of abuse is evil and must be resisted.

	paul

Internet-Drafts | 1 Oct 1998 16:21
Picon
Favicon

I-D ACTION:draft-ietf-pkix-roadmap-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) 
Working Group of the IETF.

	Title		: Internet X.509 Public Key Infrastructure PKIX Roadmap
	Author(s)	: A. Arsenault, S. Turner
	Filename	: draft-ietf-pkix-roadmap-00.txt
	Pages		: 26
	Date		: 30-Sep-98
	
This document provides an overview or 'roadmap' of the work done by the
IETF PKIX working group.  It describes some of the terminology used in
the working group's documents, and the theory behind an X.509-based PKI.
It identifies each document developed by the PKIX working group, and
describes the relationships among the various document.  It also
provides advice to would-be PKIX implementors about some of the issues
discussed at length during PKIX development, in hopes of making it
easier to build implementations that will actually interoperate.

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-roadmap-00.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-roadmap-00.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
(Continue reading)


Gmane