Subject: Re: NEW Data type for certificate selection ?

From: Stefan Santesson <[email-masked]>
Date: Thu, 01 Oct 1998 09:24:36 +0200

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                     [email-masked]
>http://novaware.cps.softex.br
>
>
>
-------------------------------------------------------------------
Stefan Santesson                <[email-masked]>
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
-------------------------------------------------------------------

---

From: Andreas Berger <[email-masked]>
Date: Thu, 01 Oct 1998 13:52:59 +0100

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

---

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

Stefan:

;-)

May I remind you that you wrote:
 
 I realize that today there is no way to do this without distributing
 customized plug-in components to end-users

However, there are actually TWO ways, as I mentioned in my previous
postings, that do not involve plug-ins and do not need Javascript
either (btw, a security risk right there).

>convinced that they should either.

;-) Simply because you perhaps want to make commercial CA-services
mandatory to Banks. However, that is neither needed to Banks nor
desirable security wise.

Further, if you want to name an objection, please do so. Generic
"does not work that way", without qualifying the "that" or why -- is
not useful in a discussion. SMTP carries only written words yet, not
thoughts ;-)

Can you be specific?

>right certificate for creating a signed object in a Java script?

As I explained before, there are TWO ways to pick the intended
certificate and no other cert. However, pls consider abandoning
Javascripts to provide *functionality* -- even though JS may add
embellishments. Several major companies and security concerned
individuals do not use JS at all.

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