Re: NEW Data type for certificate selection ?

[Ed Gerck <egerck@xxxxxxxxxxxxxxxxxxx>]

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                     egerck@novaware.cps.softex.br
http://novaware.cps.softex.br