Re: NEW Data type for certificate selection ?

[Stefan Santesson <stefan@xxxxxxxxxxx>]

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"
>
>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
>
>
>
-------------------------------------------------------------------
Stefan Santesson                <stefan@accurata.se>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. +46-40 152211              
216 42  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------