[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: spec for wire format of SPKI cert
At 11:13 AM 8/28/96 -0700, Peter Williams wrote:
>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.
SPKI is not intending to take over SET. SET has chosen their cert format
and it's clear that the process is so expensive that any change would be a
However, those of us who process SET cert chains can (and by necessity will)
generate certificate results in the form of <subject-key,auth>. If we have
multiple sibling processors generating and using those certificate results,
we can communicate them among the siblings via certificate result
certificates. Since this is entirely internal, within one shop, there is no
standards effort required.
>Concerning legal liabilities, and applications' unilateral *assignment* (a very
>legalistic term) of argeed semantics. Two parties who agree, can of course
>semantics they wish, with as much legal stuff as they desire. However, once
>a third party involved, who is not a party bound to the agreement, how does
>that person being damaged, upon relying upon the issued SPKI cert?
We have assumed all along that certificates will not be used as grocers used
to use drivers' licenses. Rather, if you choose to accept certificates from
some issuer for some <auth>, then you need to have an agreement with that
issuer to make sure you and he have the same meaning for that cert. This is
where something like Verisign's published policy statement is so important.
>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!)
This is an interesting part of the negotiation between some verifier and
some cert issuer -=- but it's an off-line legal negotiation rather than
something to do with the syntax of the certificate itself.
>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
Sorry, Peter, but I don't see the cert syntax having anything to do with
those legal agreements.
>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.
If/when Verisign issues SPKI format certs, then I believe it should make
sure they're subject to a formal policy statement, just as Verisign's X.509
certs today are. However, Verisign hasn't set the X.509 cert meaning and
especially not the legal meaning for all generators of X.509 -- only for
Verisign. The policy is attached to the issuer key, not the cert format.
The same would be true with SPKI or SDSI certs, I assume.
Am I missing something? Did I not understand you?
|Carl M. Ellison firstname.lastname@example.org http://www.clark.net/pub/cme |
|CyberCash, Inc. http://www.cybercash.com/ |
|207 Grindall Street PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2 |
|Baltimore MD 21230-4103 T:(410) 727-4288 F:(410)727-4293 |