Re: NEW Data type for certificate selection ?

[Marc Branchaud <marcnarc@xxxxxxxxx>]

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

Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable


Stefan Santesson <stefan@accurata.se> scrawled:
> =

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


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

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


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

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



-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQB1AwUBNhQbt1rdFXNdDxPlAQEtswL8CZltb8fpsRO5urWESF9Ps4FNVlO9rLui
8+eDmkaf9L7AnY+ljW7ZCYF0p8zk/f6d7xmpia+gxdQBxT6edKYOOTzsr2cwY3Hf
RITSfqoIf4XpQTy/N1lBRhGRLZ0qYYwR
=9JQx
-----END PGP SIGNATURE-----