[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: NEW Data type for certificate selection ?
Marc,
If I follow you right you suggest that I use the knowledge from the SSL
negotiation to select the proper non-repudiation cert for signing
transactions. I have thought of that but I have my doubts.
It would be very easy for the server to link knowledge from the link level
(SSL) to the Application level (Javascript). The question is if that is
possible at the client side, by only using standard components (existing or
coming).
Suppose the following steps:
1) The client browser knows which certificate was used to set up the SSL
channel.
2) The server transfer a Javascript to the client in order to create the
electronic transaction form
3) After completing the form the Javascript request a signature on the
completed form before it's transferred to the server.
Now even if the non-repudiation certificate and the SSL certificate was
issued by the same CA, Will any existing or planned version of any browser
have the logic needed to find the right certificate. Not in theory, in
practice.
If not, then the problem is real and needs a solution. And if a solution is
needed I would like to see better selective mechanisms than just Issuer DN
of the CA.
/Stefan
At 11:28 AM 10/1/98 -0700, Marc Branchaud wrote:
>Content-Type: text/plain; charset=iso-8859-1
>Content-Transfer-Encoding: quoted-printable
>
>
>Stefan, your bank application here actually requires two functions:
>
>(1) An automated way to select the non-repudiation cert to be used in ste=
>p =
>
>4, and (2) a way to let browser users create a non-repudiable signature =
>
>(setting aside for the moment the definition of what that is).
>
>This thread started out as a quest for (1). Well, that can easily be =
>
>achieved using existing mechanisms such as SSL. You already mentioned th=
>e =
>
>plastic card analogy, and it can work exactly the same way: the non-rep c=
>ert =
>
>and the SSL server's cert can share a common parent CA. When the browser=
> =
>
>receives the SSL server's cert chain the in SSL handshake, it can know th=
>at =
>
>only certs signed by one of those CAs should be used for these transactio=
>ns.
>
>It's just like the plastic cards, where the logo (DN) of the place you're=
>
>doing buisiness with matches the logo (DN) on one of your cards and so yo=
>u
>know which card to use.
>
>Now, (2) is a completely different problem, and is one that, unlike (1),
>currently requires some kind of plugin, seeing as how there is currently =
>no
>such thing as "signing a web form". However, selecting the proper cert i=
>s
>easy, since the "transaction form" that gets filled out came from a secur=
>e
>site and the SSL handshake contains enough info to match a CA to one of t=
>he
>user's certs. All that is required to to select one of the matching cert=
>s
>that has the nonRepudiation bit set, then present it to the user so that =
>he
>knows it's getting used when he clicks the button.
>
> Marc
>
>+------------------------------------------------------------------------=
>+
> Marc Branchaud \/
> Chief PKI Architect /\CERT INTERNATIONAL INC=
>=2E
> marcnarc@xcert.com PKI References page: www.xcert.co=
>m
> 604-640-6227 www.xcert.com/~marcnarc/PKI/
>+------------------------------------------------------------------------=
>+
> PGP key fingerprint: 60 11 4B 9D 4E E5 2F 47 BD C5 C2 BF 26 DF 5A E1
>
>
>Stefan Santesson <stefan@accurata.se> scrawled:
>> =
>
>> Ed,
>> =
>
>> Now this is getting really exciting. I really want to understand what y=
>ou
>> are suggesting.
>> =
>
>> How would you create a Bank application over https: ?
>> Here is some simple design requirements:
>> 1) First a secure channel shall be created (using SSL/TLS)
>> 2) Through the secure channel the customer is allowed to view accounts,=
>
>> exchange rates etc.
>> 3) The customer is allowed to enter payment transactions.
>> 4) Each payment transaction shall be individually signed using the
>> customers non-repudiation certificate issued for the purpose.
>> 5) Each transaction signature shall require the customers conscious
>> acceptance.
>> =
>
>> Now. How can you create this function without a plug-in and without usi=
>ng
>> Javascript or similar.
>> I would be vary happy to know this.
>> =
>
>> /Stefan
>> =
>
>> At 12:29 PM 10/1/98 -0300, Ed Gerck wrote:
>> >On Thu, 1 Oct 1998, Stefan Santesson wrote:
>> >
>> >>Hi Ed,
>> >>
>> >>I'm just trying to understand what you are saying.
>> >>
>> >>Are what you are saying, that you would solve the problem generally b=
>y, 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.=
>
>> >
>> >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).
>> >
>> >
>> >>Simply because many planned CA-services does not work that way and I'=
>m not
>> >>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?
>> >
>> >>
>> >>The next question is, how do I use the SSL/TLS negotiation to pick th=
>e
>> >>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 egerck@novaware.cps.softex.br=
>
>> >http://novaware.cps.softex.br
>> > -- Member of the Meta-Certificate Group -- http://www.mcg.org.br =
>
>> >
>> >
>> >
>> >
>> >
>> -------------------------------------------------------------------
>> Stefan Santesson <stefan@accurata.se>
>> Accurata Systems=E4kerhet AB =
>
>> Lotsgatan 27 D Tel. +46-40 152211 =
>
>> 216 42 Malm=F6 Fax. +46-40 150790 =
>
>> Sweden Mobile +46-70 5247799
>> =
>
>> PGP fingerprint: 89BC 6C79 5B3D 591B 8547 1512 7D11 DBF4 528F 29A0
>> -------------------------------------------------------------------
>
>
>
>
-------------------------------------------------------------------
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
-------------------------------------------------------------------