Subject: Re: NEW Data type for certificate selection ?

From: Stefan Santesson <[email-masked]>
Date: Thu, 01 Oct 1998 17:40:35 +0200

Ed,

Now this is getting really exciting. I really want to understand what you
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 using
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 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.
>
>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 the
>>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  
>
>
>
>
>
-------------------------------------------------------------------
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: Ed Gerck <[email-masked]>
Date: Thu, 1 Oct 1998 13:40:10 -0300 (EST)

On Thu, 1 Oct 1998, Stefan Santesson wrote:

>--- Message on the SEIS mailing list ([email-masked])
>
>Ed,
>

;-) commercial enquiries pls to [email-masked] 

>1) First a secure channel shall be created (using SSL/TLS)

as explained in my previous postings, with server and client
authentication in SSL.

>2) Through the secure channel the customer is allowed to view accounts,

a question for a proper cgi-bin or Java servlet at the Bank's server.

>3) The customer is allowed to enter payment transactions.

sure, why not? He has (1) and (2) above at his disposal -- with all
needed functionality.

>customers non-repudiation certificate issued for the purpose.

as explained in my previous postings, with TWO options for that
implementation.

>5) Each transaction signature shall require the customers conscious

;-) that you can NEVER guarantee over the Internet! Pls re-state your
goals and NEVER depend on that assumption.

>I would be vary happy to know this.

Well, I already tried to explain -- twice and with TWO options. Can
you tell me step by step, preferably by directly quoting my words of
the first posting where the solution was detailed, where is the
disconnect?

Cheers,

Ed Gerck

---

From: Marc Branchaud <[email-masked]>
Date: Thu, 01 Oct 1998 11:28:20 -0700

-----BEGIN PGP SIGNED MESSAGE-----

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
 [email-masked]        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 <[email-masked]> scrawled:
> =

> =

> Now this is getting really exciting. I really want to understand what y=
ou
> =

> 2) Through the secure channel the customer is allowed to view accounts,=

> =

> Now. How can you create this function without a plug-in and without usi=
ng
> =

> =

> >>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.=

> > =

> >>Simply because many planned CA-services does not work that way and I'=
m not
> >>The next question is, how do I use the SSL/TLS negotiation to pick th=
e
> >______________________________________________________________________=

> >Dr.rer.nat. E. Gerck                     [email-masked]=

> > -- Member of the Meta-Certificate Group -- http://www.mcg.org.br  =

> Accurata Systems=E4kerhet AB     =

> Lotsgatan 27 D                  Tel. +46-40 152211              =

> 216 42  Malm=F6                   Fax. +46-40 150790              =

> =