Subject: Re: NEW Data type for certificate selection ?

From: Ed Gerck <[email-masked]>
Date: Thu, 1 Oct 1998 00:48:37 -0300 (EST)

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
same type for your repudiable and non-repudiable cases (which I
possibly would not, but that is another story). As I wrote:

>> (for higher security) with a different CA cert for each type.

and, again, later in the same msg:

>> Or, for higher security, the Bank can use different CA certs for
>> each type and send their DNs accordingly, in each case.
>>

so, all you need is to have different "types" (ie, DNs) of CA certs,
where both "types" should be signed by the same root CA cert of
course and the public-key root CA cert should be included in the
distribution.

Can you pls explain what causes selection difficulties for you in the
above scenario?

>Regardless of this I fail to see how this can be used to pick the right
>"non-repudiation" certificate in the Java script application.

Please read above, I hope it is clearer now.

> I also fail
>to understand if you suggest that the current SSL/TLS functions solves all
>my problems or just a part of them.
>

;-) If "all your problems" is what you stated, sure, all at one stop.

>Do you suggest that a more general matching mechanism is not needed?
>

If the problem is what you defined, yes.

>/Stefan
>
>P.s
>Regarding hashed SSN with salt, I don't get how the "salt" solves this. If
>the salt is unknown then the SSN can't be checked and if the salt is known
>the dictionary attack is still possible.

1. The salt is only known to those entities that should know the SSN
-- not to the evildoer that is trying to get SSNs from a list of
cached client certs, in a common access area or in memory.

2. the salt is treated as client's private information -- and kept
separate from the cert, in a protected area together with other
private information from the client.

BTW, this is similar to "dividing" a SSN "signature" into two parts,
one public (in the cert) and another private (the salt).

> I would say that your "salt" is
>equal to suggest that the SSN should be encrypted with a secret key (where
>the "salt" is being that secret key).
>

Yes, certainly -- but it is more appropriately called a keyed-MAC.

BTW, I am glad that you now repudiate your phrase after your P.s
above ;-)

>You and I can argue for centuries if certificates handled in browsers
>should, or should not, be allowed to contain SSN.

No, I don't argue. As I wrote two msgs ago, some think they have
valid reasons for it and I do not disagree with the need to preserve
freedom. In that, I follow the C maxim -- even though I think that
security work is perhaps not the best place to leave enough rope so
that you may hang yourself with it if you so want or don't think it
is dangerous...

Cheers,

Ed Gerck
______________________________________________________________________
Dr.rer.nat. E. Gerck                     [email-masked]
http://novaware.cps.softex.br

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 01 Oct 1998 09:16:27 +0200

> 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, [email-masked]
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

---

From: Paul Koning <[email-masked]>
Date: Thu, 1 Oct 1998 09:11:37 -0400

>>>>> "Ed" == Ed Gerck <[email-masked]> 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

---

From: Ed Gerck <[email-masked]>
Date: Thu, 1 Oct 1998 12:15:20 -0300 (EST)

On Thu, 1 Oct 1998, Olle E. Johansson wrote:

>the database of user certificates. 

Olle:

As you can read in my previous full msg (where that part was taken
from), Stefan did not copy the following paragraph -- which I would
like to highlight and which fully answers your concern:

 It is important to note that *if* the customer's browser fails to
 authenticate the Bank's server, then this will generate a fatal
 handshake-failure alert in SSL if the non-authenticated Bank still
 tries to go into phase 2 above -- so, the second phase is privacy
 protected by the first.

Cheers,

Ed Gerck
______________________________________________________________________
Dr.rer.nat. E. Gerck                     [email-masked]
http://novaware.cps.softex.br
 -- Member of the Meta-Certificate Group -- http://www.mcg.org.br

---

From: Ed Gerck <[email-masked]>
Date: Thu, 1 Oct 1998 12:33:58 -0300 (EST)

>sort of abuse is evil and must be resisted.

Agreed 100%, especially in a public protocol. That is why I wrote
"some think thay have valid reasons".

However, freedom is never lost all at once (Hume) also means that
I must respect the desire of others -- as long and if and only if
that does not collide with mine.

Thanks,

Ed Gerck