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

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


Lets think about why compromise of a root key is bad. It allows you to
create entities which are not bonifide and commit all sorts of fraud
(and if you know its compromised then all issued certificates are
invalid). If instead you keeep a list of public keys in a secure
environment then there are also risks, while it could be argued that
they are less. If someone was able to steal the secret key in the first
scenario then it must also be possible for them to break in and insert
new public keys in the list and commit fraud that way. What you have
lost is the flexibility which a certificate offers. i.e. use in a
distributed manner.

Ian.
 ----------
  >  From: cme@cybercash.com
  >  To: Lynn.Wheeler@firstdata.com; dpkemp@missi.ncsc.mil
  >  Cc: cert-talk@structuredarts.com; cme@cybercash.com; spki@c2.net
  >  Subject: Re: [E-CARM] PKI, CAs, TTPs &c.
  >  Date: Friday, 27 March 1998 9:27AM
  >
  >
  >  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.
  >  >
  >  >
  >  >
  >
  >
+-----------------------------------------------------------------------
---+
  >  + For information about the cert-talk mailing list, including
archives     +
  >  + and how to subscribe and unsubscribe, visit:
+
  >  +                http://mail.structuredarts.com/cert-talk
+
  >
+-----------------------------------------------------------------------
---+
  >
 ----------------------------------------------------------------
Ian Littler
Product Manager, Certification Authority
Telstra
Tel: +61-2-99033540, Fax: +61-2-99033466
email: ilittler@nibupls1.telstra.com.au
 ----------------------------------------------------------------
Follow-Ups: