[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: spec for wire format of SPKI cert
Bill,
Im not using the term "delegation", as in "DNS name context" delegation, or in
legal "authority-to-use-asset" delegation, where asset may happen to be signing
key. So, lets not get on the PGP rant; this is not how Im using the term.
Im using the term in the object oriented system sense, where
a process which makes an IPC exchange with another process
is delegating "responsiblity to behave/transact" to that second process.
The first process "relies upon" the second to behave properly,
once the interface semantics are agreed during the estbalisment
of the association (where the association may be legally reecognisable,
or not).
Should spki certs follow a capability design? yes, essentially. We
have already deployed a limited capability design here (though using
a different encoding format), and Im really happy to see thats
the SPKI basic theory is capabilities, with a decent theoretical
basis. How one turns SET protocol into a capability systems
will be amusing, given the business requirements; the spki acitivtity in
certs for bankcard payment systems also breaks
the agreement IETF/IESG has with VISA/MC not to do standards in
this area, so there is minimal overlap of efforts between these
coordinating groups. Ill notify IESG.
Concerning legal liabilities, and applications' unilateral *assignment* (a very
legalistic term) of argeed semantics. Two parties who agree, can of course agree any
semantics they wish, with as much legal stuff as they desire. However, once there is
a third party involved, who is not a party bound to the agreement, how does one stop
that person being damaged, upon relying upon the issued SPKI cert?
And, perhaps as importantly, how does one ensure, as a cert issuer (yourself
or a CA) that you, under common law as unmodified by statue or
contract/agreement, are not liable for any such damages, should they
occur? If I understand the local lawyers right, all of us - in common law
countries - have a duty to doing nothing which damages others, and
we must be able to demonstrate that we *all* either agree that the issuer
be held-harmless, or the certs *are* uniformly harmless (but still useful!)
Part of the answer, we believe lies back in the notion of issuing policy,
which is why (still) we like X.509 v3's model as it deal formally with
the instrument. Though Carl (and the spki I-D) rant about X.509
profile design known a PEM and its identity-public-domain policy notions, we
(VeriSign) here have not deployed any such type of policy, having profiled
the standard and our conforming services to implement a more straigthforward
authentication service, where technical (and, through reference, legal) a new
element of prevailing policy (known as certification practices) is used to address
the issues I have herein raised, amongst many others.
I suspect as SPKI certs model evolves, we will need to faciliate
a formal policy instrument, and learn the same lesson X.509
v3 learned over X.509 v1. If we dont provide for it, (as in X.509 v1),
people will imposed policy anyway, though informal means, leading
to PEM style policydomain interoperability problems, and unatural technical
system designs and procedures, to get back what the instrument
they need to handle the commercial risks.
Peter.
----------
From: Bill Frantz
Sent: Tuesday, August 27, 1996 11:56 PM
To: Peter Williams
Cc: spki@c2.org
Subject: RE: spec for wire format of SPKI cert
At 9:02 PM 8/27/96 -0700, Peter Williams wrote:
>I do agree that the notion of controlling delegation is the most simplistic
>security policy model Ive thought about myself, and one which is increasingly
>necessary for the object protocols now emerging into practice on the web.
To repeat myself: As long as a legitimate user can set up a proxy service
to use a cert you gave him you can not prevent him from effectively
delegating the authority given by that cert. In other words, the limits on
delegation in a cert are of the form "please don't delegate or we will
punish you" rather than "you can't delegate because the mathematics and
logic of the system prevent you from doing so".
Because of this fact, "don't delegate" should not be depended on where real
security is needed.
>Assuming the Internet becomes a distributed object system, one can
>perhaps begin to conceive of certs not as an ancillary mgt security
>infrastructure, but as the point of expression and control of interface
>brokerage between cooperating objects. Just as an X.509 cert is really a
>mini-Directory entry, so the delegation-cert is a authorised-configuration
>utility for both comms paths and interworking assumptions.
SPKI certs act a capabilities in a traditional capability system. As such
they combine authentication and authorization in one package.
>A reliable liability model depends upon
>constrained data handling with well-defined meaning; and SPKI certs
>sometimes seem to be self-defining semantically; and this property makes
>life difficult if the certs are ever to control commercial risks,
>control hazardous, or military weapon systems.
Much of SPKI certs (the <auth> fields) are defined by the application.
Applications are perfectly capable of assigning well-defined meanings to
the <auth>s they define.
-------------------------------------------------------------------------
Bill Frantz | Cave ab homine unius lebri | Periwinkle -- Consulting
(408)356-8506 | [Beware the man of one | 16345 Englewood Ave.
frantz@netcom.com | book] - Anonymous Latin | Los Gatos, CA 95032, USA