[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: NEW Data type for certificate selection ?
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
dwightarthur@mindspring.com 55 Water Street
http://www.nscc.com New York, NY 10041-0082
-----Original Message-----
From: owner-ietf-pkix@imc.org [mailto:owner-ietf-pkix@imc.org] On Behalf Of
Marc Branchaud
Sent: Thursday, October 01, 1998 8:18 PM
To: 'ietf-pkix@imc.org '
Subject: Re: NEW Data type for certificate selection ?
-----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-----