RE: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))

[Stephen Kent <kent@xxxxxxx>]

Lynn,

>It isn't so much that it is applicable to "closed-systems" ... it is
>applicable
>to systems that create some front-end sign-up/trust relationship and then
>perform on-going transactions based on more global trust equation that isn't
>atomic & self-containable on a per transaction basis (like information
>aggregation ... i.e. account balance which is the combination of all deposits
>minus all debits/withdrawals)
>
>certificates are useful in situation for providing "on-the-fly" trust
>where none
>previously existed. for random interactions this basically combines both the
>transaction and the trust information into a single operation (where the scope
>of the trust propogation can be transaction atomic and self-contained
>within the
>definition of a certificate authorities policy and practices).

I'm of the school that says that certs don't establish trust at all.  They
represent relationships, often paralleling physical world relationships,
and allow users to make authorization decisions bases on the authentication
identities represented by the certs.  In the best cases, they parallel real
world authoritative relationships, not TTP "trus me" relationships.

<snip>

>in the x9.59 scenerio ... while the bank card transactions appear to operate
>between the consumer and the merchant ... in reality the merchant is
>acting as a
>transaction conduit to the consumer's financial institution ... where the
>consumer is instructing their financial institution to transfer funds from
>the consumer's account to the merchant's account
>
>possible objective for certificates is being useful for trust propogation in
>environments currently lacking existing trust infrastructures. webserver
>comfort
>certificates are useful in providing such trust ... even without certification
>authority infrastructures (i.e. simple certificate manufactoring processes).
>
>so looking at banking ... the issue for certificates is looking at the part of
>the business process where trust establishment enters into the equation
>... and
>being able to leverage the trust propogation characteristic of certificates.
>
>It isn't so much whether there is an open or closed characteristic ... it is
>whether the trust establishment occurs on every transaction or if there is an
>business infrastructure that has a setup/sign-up phase for establihing trust
>(i.e. setting up a bank account and maintaining the existing bank account
>balance).
>
>So, to the extent, that certificate authority policy and practices covers
>areas
>of trust propogation that coincides with trust attributes needed in the
>signup/setup process ... then specific certificate trust propogation is useful
>at that setup/signup point.

I agree with your characterization of how merchants, consumers, and issuing
banks relate to one another in bank card tranactions, something well
modeled by SET.  But the word "trust" appears in your later text way too
many times :-). I  don't beleive that trust is generally transitive, not
being a PGP kinda guy, so the phrase "trust propagation" also worries me.
Delegation of authorization might be more appropriate, in many instances,
but transitive trust is an awfully squishy notion that is hard to process
in an algorithmic fashion.  Most of the atetmpts we see to do this yield
counterexamples.

Steve