[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [E-CARM] PKI, CAs, TTPs &c.

Lynn,

	the scenario you describe below sounds like what
SPKI covers by having an ACL (this time at the bank) that
directly empowers a public key.  There are no certificates
in such an operation, unless you consider the ACL entry
to be a kind of certificate (one that has no issuer
and doesn't need to be signed).  Did I interpret
your design correctly?

 - Carl

>From: Lynn.Wheeler@firstdata.com
>To: dpkemp@missi.ncsc.mil
>Cc: cert-talk@structuredarts.com, spki@c2.net
>Subject: Re: [E-CARM] PKI, CAs, TTPs &c.
>
>
>i have scenario for financial transactions that is very close to
>trust begins at home
>
>the financial institution verifies the client's authentication and public
>(i.e. certification authority; the financial institution slash
>certification
>authority may choose to also issue a certificate to the client).
>
>the client creates a payment instruction against their account
>at their financial institution ... and digitally signs the payment
>instruction. the payment instruction flows thru the financial
>infrastructure ... and eventually arrives at the client's financial
>institution for execution/fulfillment. The client's financial
>institution can verify the digital signature on the payment
>instruction using the digital signature on file in the client's
>account record (placed there during the CA registration
>process).
>
>it has the additional advantage of
>
>1) being very bit compact easily flowing digital signatures
>thru existing financial infrastructures
>
>2) lacking systemic risk introduced with certificate signing ...
>i.e. there is no CA/root key compromise attack that can
>take down the financial infrastructure (since no certificates
>are being used ... digital signature verification is not
>dependent on certificates that may all become invalid
>because of CA/root key compromise)
>
>The client financial institutions can choose to issue
>signed certificates as part of the certification authority
>registration process ... and such certificates can
>be used in applications where the systemic risk of
>CA/root key compromises is less onerous.
>
>
>