# RE: Request for 1.2 Feature

jgindin@walldata.com
Fri, 23 Jan 1998 15:22:30 -0800

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Previous message: Jan Luehe: "Re: DH key pair generation is really slow"

    From: jgindin@walldata.com

    Message-Id: <199801232358.PAA22987@java1.javasoft.com>

    To: David.Brownell@Eng, gong@games.eng.sun.com

    Subject: RE: Request for 1.2 Feature

    Date: Fri, 23 Jan 1998 15:22:30 -0800

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------ =_NextPart_000_01BD2818.3B96D9F0
Content-Type: text/plain;
charset="iso-8859-1"

Just curious if anyone's come up with any potential solutions?

Thanks!

Jay Gindin

-----Original Message-----
From: Gindin, Jay
Sent: Friday, January 16, 1998 10:01 AM
To: David.Brownell@Eng.Sun.COM; gong@games.Eng.Sun.COM
Cc: java-security@web1.javasoft.com
Subject: RE: Request for 1.2 Feature

See my responses below.

> -----Original Message-----
>
> > The problem, in a nutshell, is that I cannot trust the caller of a
> > method to honestly tell the called method who he is.
>
> Right ...
>
> > I'm particularly
> > interested in being able to determine if the caller implements a
> > particular interface, ISecureObject. If I (the called method) know
that
> > the caller implements that interface, then I can interrogate the
caller
> > for authentication information (i.e., calling a method like
> > ISecureObject.getCertificate()). At that point, I know that I'm
getting
> > the real information about the real caller.
>
> But do you really have reason to trust what the object chooses to
> tell you about itself?
>
> class EvilCaller ... implements ISecureObject {
> ...
> X509Certificate getCertificate () {
> return highlyTrustedCertificateOfSomeoneElse;
> }
> ...
> }
>

You're correct, except that (in this case) I happen to know that the
objects in this system extend a base class whose getCertificate
implementation is a final method, and the java.security.Certificate
member field is private to that base class. There is no
setCertificate() method so, in theory, there's no way for a derived
class to return back someone else's Certificate.

However, you bring up a flaw in my thinking--I've been too narrowly
focussed on the problem as it currently exists. I need to ensure that
down the road, it will be possible for classes to implement the
ISecureObject interface without deriving from a particular base class.
At that point, the scenario you present above becomes a very real
possibility...

> I can't speak for Li, but for me what'd be more useful is to hear from
> you about problem you're trying to solve, rather than the solution you
> would like to see (getting an ISecureObject). The JDK does record
data
> about who signed a class; is that what you want to use? What do you
want
> to do with the information you retrieve from ISecureObject ... can you
> use the JDK's policy support? Should it relate to the user who at
some
> level caused the call, rather than the software developer who coded
it?
>
> - Dave
>

The problem I'm trying to solve, as stated above, is runtime
authentication of the caller of any particular method. In addition,
there are multiple levels of authentication that I must have:
1. The certificate of the code signer. This information I
presume I could get from the JDK, though I'm not sure exactly how.
java.lang.Class.getSigners()? java.security.SignedObject?
java.security.CodeSource? Some other way?
2. The certificate being carried by the object. This
certificate is actually the certificate of the user (i.e., Jay Gindin's
certificate) who created the object. I believe that this is the same as
your question above about relating to the user who caused the call, as
opposed to the software developer. (It is important to note that method
calls will not all be directly attributable to a user's (immediate)
action. For example, an object may (based on runtime criteria,
including system properties, time of day, etc...) "decide" to perform
some action.)

As for being able to use the JDK's policy support, I could see the
method that needs to be protected creating a new Permission object, and
then invoking the AccessController.checkPermission method. However, I
still need to get the information listed above.

Please let me know if you need more clarification.

Jay Gindin

------ =_NextPart_000_01BD2818.3B96D9F0
Content-Type: application/ms-tnef
Content-Transfer-Encoding: base64

eJ8+IjsAAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQSAAQAcAAAAUkU6IFJlcXVlc3QgZm9yIDEuMiBGZWF0dXJlAN4I
AQmAAQAhAAAANjk5MDI4Mjk4MzkyRDExMTgzNTgwMDYwQjBBMTJEQTAAwwYBIIADAA4AAADOBwEA
FwAPADkAHwAFAFkBAQWAAwAOAAAAzgcBABcADwAWAB4ABQA1AQENgAQAAgAAAAIAAgABA5AGABgO
AAAvAAAACwACAAEAAAALACsAAAAAAAMALgAAAAAAQAA5AOC2ocZVKL0BHgBwAAEAAAAYAAAAUmVx
dWVzdCBmb3IgMS4yIEZlYXR1cmUAAgFxAAEAAAAgAAAAAb0ioUZlW3YkGY4AEdGwZgCgJIOL5QAA
VJlQAWyt5BAeAEIQAQAAAAEAAAAAAAAAAwDeP+QEAAADAAFuIAAAAAsADoALIAYAAAAAAMAAAAAA
AABGAAAAAACIAAAAAAAACwAPgAsgBgAAAAAAwAAAAAAAAEYAAAAABYgAAAAAAAADAAWACCAGAAAA
AADAAAAAAAAARgAAAAABhQAAAAAAAAsAAYAIIAYAAAAAAMAAAAAAAABGAAAAAAOFAAAAAAAACwAA
gAggBgAAAAAAwAAAAAAAAEYAAAAADoUAAAAAAAADAAaACCAGAAAAAADAAAAAAAAARgAAAAARhQAA
AAAAAAMAB4AIIAYAAAAAAMAAAAAAAABGAAAAABiFAAAAAAAAAwACgAggBgAAAAAAwAAAAAAAAEYA
AAAAEIUAAAAAAAADAAOACCAGAAAAAADAAAAAAAAARgAAAABShQAAxxIAAB4ABIAIIAYAAAAAAMAA
AAAAAABGAAAAAFSFAAABAAAABAAAADguNQAeAAiACCAGAAAAAADAAAAAAAAARgAAAAA2hQAAAQAA
AAEAAAAAAAAAHgAJgAggBgAAAAAAwAAAAAAAAEYAAAAAN4UAAAEAAAABAAAAAAAAAB4ACoAIIAYA
AAAAAMAAAAAAAABGAAAAADiFAAABAAAAAQAAAAAAAAADACYAAAAAAAMANgAAAAAAHgAxQAEAAAAQ
AAAASkdJTkRJTjhDOUM3RUNDAAMAGkAAAAAAHgAwQAEAAAAQAAAASkdJTkRJTjhDOUM3RUNDAAMA
GUAAAAAAAgEJEAEAAAAgCQAAHAkAADYRAABMWkZ1h7jvVocACgENA0N0ZXh0Aff/AqQD5AXrAoMA
UALzBrQCgyYyA8UCAGNoCsBzZdh0MCAHEwKAfQqACM8/CdkCgAqECzcSwgHQIEr0dXMFQGMIcQhg
BCAGkMogAHB5AiBlJwQgBaAhB4AgdXAgA/B0aHEYwiBwbw7wAjAHMSCacwbwdRrAAiBzPwqjCwqF
CoBUE3Bua3MhqRu8SmEaUEcLgGQLgVMbyxu1IC0f4k8FEGcLC4Aa4U0HkHNhZ2WrH+MbtUYDYToe
FSwXwD8d8Bu1BmACMCIwIfBpZDMd8CKybnUKwBpQMTYhIrAxOTk4JMAwOlQwMRPgTRwmbyIwRKRh
diPwLkIDYHcZEABsbEBFbmcuUwB1bi5DT007IEJnAiBnQGdhB4EuUyeJG7VDYyIwaiagYQYtE6AY
InR5QHdluGIxLipiGxABgC4ZYTEjBnViagWQI6FSRfktMWVxClAX8QIQBcArcKIyI8BlYXQIcGUe
j9sjNBmQbRpQFUBzGnAAgK0HkWInQCcQLhu8Ph/fvSDvPjI3MqAckBmQcANguQJgZW0isAuAGMAg
JHD8dHM1oCdQNkEEIBoALrBsIEkYEABwbhqAN3ByvxfiGgAZkDfwJ1AEkCAr4D8YwDTpB4AaAARw
N3BvIPc6kBkQF/BsGlAO8CdQOLj7OrA6ZXc6kDrwGZAEADG21TTYUjMwaAVALj8QPa/nNNABkTfA
J20aYArAGsD7GCALYHI7YDTpC4AO8DDB3w7wOrA2YTFgC4BnGMA2Afc6wgEAQoFtC4A9URiwOMn/
B3ALUDYgGqEEIDmqQPhCVGpmANBlIrBJBmAYIWVyTyzjLiA3wBiwN9Ao8TvvKSBrOCAH4DeCNOn/
RP9GAzeDR8k4wQOgN9NCVL8DYCigDvA4uTTpLhJhG0D/TrFBIS6wG2E2US4RAMBSQ+AoaS5lLiKw
OQJDY3s6VlPway72NVJIfCEQdBZDBJAawGZSEmUoKfopSUFBOKI3oRpwQmFIUf9K+ECjVqEawCeQ
S50VQBrhf1KaAaAIYDikWzM5BD8/INpCXHFkOuAY8HVbIzth/RNwdlsTGxADoDrROGQ9AL83oTjC
NfAs8hgQOpBvMSJ/OtAyNzuTXyJcRBnwE6BsbmYbpjTYZbJjC2AEEUX5JrBsQzkUPxFFmkh7AzAf
AAAyRkBjPxlphFg1MP45VtlAY1asSbBK4GjuZbK3FUAuwQOgaD7BO2BUOHI7CYBW2U8GoBlxGQFF
bOUToDtpDFx9aQ9lO3JI9Ru8WQhgJxVAGVFPkC0B/yKwDwBIMAUxN4NTUGBxbwA7GUErwGVK4DfQ
E3BwcD9OwTrRWPhheBiBd6Vzeb9CwUDQDwEJ8DqwNpBieCH/ZfU9AXwxbD1Fp1I1RjEuAH8zUzpk
IrAAcDqxNaEqYi7/KrYn8Gx5B4AG0DlBVyAnQPdC8QQgNdBpKoBP4mChN5L/fBhJQTWRdgE3UTgg
GwBWvf86VhsQNkM4wQWwJCE4wRVA+xkxhbF3HfFRY0QRg2E8Yc9mBDrRbpV8EGNrGwFww192sHEh
GTFW2TG9SCcQZe1f8HIisF8iYgUQQ3EZsf9/MQtgB+A2YTCRd8EcwENh/zLAQLBf8TFgeNM64DNg
T5H+dzthAhAYIAQQPGFgYjWo/xjAGIEYAxVAAjA7YQ8ABAC/NtBJQjagCeA6swnwcy7Rzzd0XvAn
IFrkb2GAAZPx3wPwO7ExYBphBBBpQ7IuEv9mA2JzRZg4s2gMR8cZ01xi/4mjQ2IDUjaBRxmEW1ft
OML/BPAJ8ArAGFBfEzXQB5CaMv9cQZDzGWJ/Eo5BMKIa4ZhU3wMQgVI/JzHON9MnBUAw4KcuoItQ
LhJMaSKwYlxx9y4SGYFhIic6sJghBGB2Af8X4AEQQVA3Qz0iCsEDUjI332Ook0ZfIXXyOGB5Q2I6
0fcbEV/wIrByLrCFMTdykuT3GxZfEjI3dwhggvFU0qyDfTBhKFnVGMFIbFeiNZJK/ERLXuEHkXZh
BbA6sCQA3wGQMjdcRD0CAJBnGRB70v9mAygwN1ZhI18iiQCaQjrg9aihP0lQV5Z0tudiyEQB/4jh
GfI4wlKaXyQ4YAiQX/H/nUNoDGcSTxKuyqihOLOysfcZMRpwU/BjGlCWEHiwFOH9t+FTnGGC8gVA
FUALYIOm/6iDBcA9Ajehi3IyNzYQX/D/XRKooYBUOQKtHxsBAYCJAPd2AQEAw7FveMDCNAWgAQD/
wNJkrzKwJoJVB6Q/HFSTKP9Asqwvk8EX8E/Re9Ghwjcz/zhwGrEZgVGtOXE4zRpCRyj3OmRJQjZx
ZB5QG1KINRjA/XYBbUFQGsBFwcOEBCA5ct9RvDeF1AAX8V/SOhu2QHL/K3A1g0gwbIjQBgRxtRRd
gN+FAjdRUpo30KEydRmBN9H/r5NWoZ00vtVOgghgPtBAo/84IpYTDwAA0DtSOpAxoElQt4CzC2An
kUOEs1ahU9nz3nNXgLfhgLzhE2RI5OGv/whQAQBwoAhwSDDAUhlyGoDvrWKJARunQHIy2A9DNTfw
/0+QCJCoAZASYZbaRthqfwL/LRAkgF+SOMPYf8H0U1Ud6P8ZMlboSuDHM1sxQtLpSzfQ/zFhu9N5
hdqSN2KgQSixk7L/XyEFwC2zXAVf8VxEwSOsVf/By8P/k8HG4JhRlZTFz8bT+UlAKElN0RiBRbAU
4bdF/zghlkU6ZTkCfKGX4jgiORH/mBIeUHZiO2EusLuxpwFDpu82kMICGTFTUG0HgB5Q72P33yEb
YUlBRgWx3wFFsoAS92GmCCAaUCh8EpKzzpbv8NsZ8AZxYTZCZgB1HlFDgP97FTXRxvEawAeQToHO
0jlxWyQDE7BjPxFK4CIOEGP5I/BlIjrCxvFSsotjAJb6KRu8QX8QLhJDTL6fv6n/WLLcRLBiOMI6
ZjeSlXKKY/+YIgXAGpC9IIny8AJUBBkQ/Y+wUERSmHHP0izjgBdPMsx2b5ByOLNBY0gwilC/5IAa
sAXAXVNiILNQaxH5/9IHjgc30PPx/OKVhdyiul7vU/BCw6GzMb1QNhB8IjYQ//vSSvREwWOilXOo
U2YBgUAvbLMA0sps7hh9IFADAIAQ/////wIB+T8BAAAAVAAAAAAAAADcp0DIwEIQGrS5CAArL+GC
AQAAAAYAAAAvTz1XQUxMREFUQS9PVT1FWEhRMDEvQ049TVNNQUlMVVNFUlMvQ049SkdJTkRJTjhD
OUM3RUNDAB4A+D8BAAAAFgAAAEdpbmRpbiwgSmF5IChNUyBNYWlsKQAAAB4AOEABAAAAEAAAAEpH
SU5ESU44QzlDN0VDQwACAfs/AQAAAFQAAAAAAAAA3KdAyMBCEBq0uQgAKy/hggEAAAAGAAAAL089
V0FMTERBVEEvT1U9RVhIUTAxL0NOPU1TTUFJTFVTRVJTL0NOPUpHSU5ESU44QzlDN0VDQwAeAPo/
AQAAABYAAABHaW5kaW4sIEpheSAoTVMgTWFpbCkAAAAeADlAAQAAABAAAABKR0lORElOOEM5QzdF
Q0MAQAAHMKDmVVBVKL0BQAAIMAQ/qKpaKL0BHgA9AAEAAAAFAAAAUkU6IAAAAAAeAB0OAQAAABgA
AABSZXF1ZXN0IGZvciAxLjIgRmVhdHVyZQALACkAAAAAAAsAIwAAAAAAAwAGEDexjakDAAcQmAsA
AAMAEBAAAAAAAwAREAAAAAAeAAgQAQAAAGUAAABKVVNUQ1VSSU9VU0lGQU5ZT05FU0NPTUVVUFdJ
VEhBTllQT1RFTlRJQUxTT0xVVElPTlM/VEhBTktTSkFZR0lORElOLS0tLS1PUklHSU5BTE1FU1NB
R0UtLS0tLUZST006R0lOAAAAAN5T

------ =_NextPart_000_01BD2818.3B96D9F0--

- Previous message: Jan Luehe: "Re: DH key pair generation is really slow"