Subject: Re: NEW Data type for certificate selection ?

From: Stefan Santesson <[email-masked]>
Date: Fri, 02 Oct 1998 00:47:37 +0200

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
> [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:
>> =
>
>> 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                     [email-masked]=
>
>> >http://novaware.cps.softex.br
>> > -- Member of the Meta-Certificate Group -- http://www.mcg.org.br  =
>
>> >
>> >
>> >
>> >
>> >
>> -------------------------------------------------------------------
>> Stefan Santesson                <[email-masked]>
>> 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                <[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: Marc Branchaud <[email-masked]>
Date: Thu, 01 Oct 1998 17:18:00 -0700

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

> If I follow you right you suggest that I use the knowledge from the SSL=

> transactions. I have thought of that but I have my doubts.

Not necessarily from the SSL handshake itself (although since that's
already there it would be an optimization).  But the same kind of mechani=
sm
could be employed, i.e. "here's a list of CAs whose certs I can accept."

> It would be very easy for the server to link knowledge from the link le=
vel
> (SSL) to the Application level (Javascript). The question is if that is=

> possible at the client side, by only using standard components (existin=
g or
> coming).

So, you have this new requirement that nobody's really though of yet, and=
 =

you're wondering if existing or planned components will solve your =

problem.  Hmmm....

> 1) The client browser knows which certificate was used to set up the SS=
L
> channel.
> 2) The server transfer a Javascript to the client in order to create th=
e

> 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 brow=
ser
> have the logic needed to find the right certificate. Not in theory, in

In practice, no such Javascript program exists so, practically speaking,
one would have to plan one's Javascript program to have such functionalit=
y.

I'm not familiar with web scripting languages, but I imagine that it's
possible to get the issuer DN of the server's cert and/or all the certs
presented by the server in the SSL handshake.  Whether that's existing or=
 =

planned, I have no idea.

As for whatever matching rule is required, it will most likely be =

implemented by the applet than the browser.  I expect few browser makers =

would be happy to write some kind of generic lookup function to answer =

queries of the form "I need a cert of type <fee> that has a <foo> and =

isn't <foe> but can be <fum>".  They'd be much happier to simply expose =

the broswer's certificate store to the applet and let the applet do the =

search.

> If not, then the problem is real and needs a solution. And if a solutio=
n is
> needed I would like to see better selective mechanisms than just Issuer=
 DN
> of the CA.

This, I think, is the crucial issue.  I'm having trouble seeing why
matching issuer DNs is inadequate.  Is it because having a CA per =

application is impractical?  Since we're talking about banking here, I =

can't believe that the answer would be "yes" [heck, with a moderate =

hierarchy, the user would only need one cert (from the root CA) to use al=
l =

of the bank's applications].

Please explain to me why saying "I need you to use a cert signed by one o=
f =

these CAs" isn't a good enough solution.

		Marc

---

From: "Dwight Arthur" <[email-masked]>
Date: Thu, 8 Oct 1998 15:28:33 -0400

In banking applications for the "big market" I do not think that you can
assume that you know the issuing CA or its root. Effective "big market"
applications need to deal with the case where the Relying Party and the
Subject are involved with entirely separate banking entities that subscribe
to the necessary hierarchies, cross-certification communities, etc to
construct a usable chain.

In the US Securities Industry (http://www.sia.com/sirca/) we are seeking
ways to meet this need by the use of certificate policies. Certificates
usable for a particular purpose will be recognizable by the fact that they
reference the required policy OID (or, can map to it through policy
mappings).

There is a definite shortage of client-side and server-side protocols for
completing a certificate chain that's restricted to certificates meeting
policy requirements. I believe that we will be articulating some business
requirements by year end that will stimulate some further work in this area.
--------------------------------------------------
p:(212) 412-8687                     Dwight Arthur
f:(212) 908-2345        Managing Director: Systems
b:(917) 646-6682      National Securities Clearing
[email-masked]        55 Water Street
http://www.nscc.com        New York, NY 10041-0082

-----Original Message-----
From:	[email-masked] [mailto:[email-masked]] On Behalf Of
Marc Branchaud
Sent:	Thursday, October 01, 1998 8:18 PM
To:	[email-masked] '
Subject:	Re: NEW Data type for certificate selection ?

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

vel

g or

problem.  Hmmm....

L
e

ser

planned, I have no idea.

search.

n is
 DN

		Marc