[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: NEW Data type for certificate selection ?
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"
2) You suggest hashed SSN (social security numbers) using "salt"
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.
Regardless of this I fail to see how this can be used to pick the right
"non-repudiation" certificate in the Java script application. I also fail
to understand if you suggest that the current SSL/TLS functions solves all
my problems or just a part of them.
Do you suggest that a more general matching mechanism is not needed?
/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. 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).
You and I can argue for centuries if certificates handled in browsers
should, or should not, be allowed to contain SSN. The fact is that many
organizations require this and they will create those certificates
regardless of whether you and I like it or not. All we can do is to try to
help building architectural principles that to the greatest extent is as
forgiving as possible for those examples of bad engineering that by
provable fact will show up out there.
D.s.
At 03:08 PM 9/30/98 -0300, Ed Gerck wrote:
>On Wed, 30 Sep 1998, Stefan Santesson wrote:
>
>>
>>Alan, I don't suggest any new certificate extensions
>>Ed, I don't want to define any universal criteria for how certificate
>>selection SHALL be done or any who decides what for whom, regulations.
>
>Stefan:
>
>Thank you for changing the focus and not requiring (as in your
>previous examples) that Alice would have her SSN in a public cert :-)
>
>Your question below fits now the first part of my previous reply,
>with a direct solution in SSL, as I present below.
>
>>
>>All I want to do is to define some mechanisms that CAN be used, if
>>required, by local PKI-related services in order to make it POSSIBLE for
>>them to build working services with STANDARD components.
>>
>>Let me highlight this again and describe a realistic problem relevant to me.
>>
>>Bank A offer web-based banking applications. This requires the end user to
>>get a specific certificate issued by Bank A. The certificate and the
>>corresponding private key is processed through the standard web browser of
>>the client.
>>
>>Two certificates and private keys are used in the normal process.
>>1) Certificate for SSL (TLS) security
>>2) Certificate for non-repudiation protection of Bank transactions.
>>
>>In addition to these certificates, a specific end-user may be populated
>>with several other certificates, un-known to the Bank.
>>
>>The question is. How can this Bank create a web based application without
>>distributing a customized client plug-in for the purpose.
>
>
>Suppose the Bank signs its own CA certificate and uses that
>self-signed CA cert to sign all Bank customer's certs of a certain
>class (to make your problem still more realistic), for types (1) and
>(2) above for each customer or, (for higher security) with a
>different CA cert for each type.
>
>Of course, that CA cert can be easily registered in a costumer's
>browser -- just using the standard menu options. This is justifiable
>regarding trust acceptance by a Bank's customer, because the Bank
>already exibits trusted functionality to the Bank's customer and the
>Bank's CA cert is used in the realm of said trusted functionality in
>regard to the customer's browser in cases (1) and (2) of your
>example. In other words, it requires no new assumptions, for neither
>party.
>
>Now, you have two phases:
>
>1. The customer's browser must automatically authenticate the Bank's
>server, using the pre-acquired and trusted public-key Bank CA cert.
>
> If the Bank's server sends its server cert to the browser in SSL,
> right after the "server hello" message and self-signed by their own
> CA, the browser will be able to automatically verify and accept the
> Bank's server cert -- since it can be checked by the public-key
> contained in the Bank's own self-signed CA cert stored at the
> costumer's browser.
>
>2. The Bank's server must authenticate the required customer's cert,
>which is appropriately requested by the Bank's server and is
>automatically presented by the customer's browser according to cert
>class and cert type, from a larger collection.
>
> Since the Bank's server is non-anonymous, it can automatically
> request the intended cert from the browser by sending only the DN of
> their own appropriate (ie, for that customer's class) CA cert in the
> "certificate request" message sent from server to browser in SSL --
> which Bank CA cert is exactly the one that signed the required
> customer's cert. Since the Bank certainly did not use their own CA
> cert to sign any other types of certs for the customer, the Bank
> (and the customer) can trust the browser/SSL combination to block
> other customer certs that could have been selected from the
> customer's certificate pool and sent back in response. The server
> can also specify in the "certificate request" message the customer's
> "certificate type" it is requesting, as needed by the Bank -- for
> example in your cases (1) and (2) above. Or, for higher security,
> the Bank can use different CA certs for each type and send their DNs
> accordingly, in each case.
>
>
>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. Perhaps, this also answers some of your
>previous concerns and could allow more sensitive information (from
>the customer) to be included in the customer's cert sent to the
>server -- but, by all means, not in plain (eg, the SSN itself) if
>privacy is really a concern since public client certificates are
>stored in general access areas at the server.
>
>
>Regarding possible problems of using hashes to protect US's SSN
>numbers in public certs (as I suggested in my previous reply), I
>include below one comentary I received and my reply -- since it may
>be also useful in your context:
>
>===============================
>>This does not help. American SSN is only 9 digits long and only
>>includes digits. It will be trivial to do a dictionary attack in
>>this case. This may be true for other pieces of sensitive info as
>>well.
>
>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.
>
>Part of this technique is used in the MC-DN token in the
>Meta-Certificate Standard being developed by the MCG. See
>http://www.mcg.org.br/mcfaq.htm
>
>===============================
>
>
>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
-------------------------------------------------------------------