1. GGF11 Naked Keys1 Naked Keys Lynn Wheeler Chief Scientist First Data lynn@garlic.com

2. GGF11 Naked Keys2 Certificates  certificates armor data that nominally is a static subset of data nominally found in some business process infrastructure  it allows the certificates to venture out into hostile environment outside of normal business process protection  original design point was offline email from the early '80s  dial-up  exchange mail  hangup  process mail in offline environment  design point was pre-70s environment, upgrading offline physical credentials to electronic credentials but retaining the offline paradigm

3. GGF11 Naked Keys3 Certificates  first heard of x.509 (in conjunction with x.500 directory infrastructure) at early 1990s ACM sigmod meeting where somebody talked about a bunch of ISO networking engineers re- inventing 1960s database technology  next involvement in certificates was to do with electronic commerce  asked to work with small client/server company to implement payments  two people we had worked with at Oracle on parallel Oracle and cluster scale-up were now in charge of something called commerce server  spent year working on business process and implementation  needed to perform due diligence on business process of major certification authorities

4. GGF11 Naked Keys4 First Certificate Scenario  electronic commerce and domain name server certificates  certificates addressed “really talking to correct server” from domain name infrastructure trust issues  certification authorities have expensive and error prone identification process  accumulate identification information  match to real world entity  match real world entity to domain name owner on file with domain name infrastructure

5. GGF11 Naked Keys5 First Certificate Scenario  "fix"  domain name owner registers naked public key with domain name infrastructure  domain name owner digitally signs a request for certificate  certification authority validates the certificate request using naked public key on file with domain name infrastructure  transforms an expensive and error prone identification process into a much simpler and reliable authentication process  "problem"  if the certification industry can use the DNS naked public keys then possibly so could others, eliminating need for domain name certificates

6. GGF11 Naked Keys6 Second Certificate Scenario  mid-90s financial transaction specification  extreme problems with any meaningful data in x.509 identify certificates;  personal privacy issues (identity)  institutional sensitive information (access, authorization)

7. GGF11 Naked Keys7 Second Certificate Scenario  solution: relying-party-only certificates  public key registerd with institution and recorded in account record  institution records original certificate in account record  institution transmits copy of certificate to consumer  consumer originates 60-80 byte financial transaction  consumer does 128-byte digital signature  consumer packages transaction and signature with 4k-12k byte certificate  institution receives transaction  institution retrieves account number from transaction  institution retrieves account record with public key  institution verifies signature  certificate is redundant and superfluous and never used, but does increase the transaction payload by two orders of magnitude

8. GGF11 Naked Keys8 General Certificate Operation  relying party substitute for having their own business process and/or having online access to “real” process  transition since the '70s have been that business process (with any value) have instituted their own business process and/or have online access to real business process  real-time information  aggregation of patterns  transactions containing any value  door badge entry systems  financial transactions  online system authentication and access  purchase cards instead of checks  law enforcement checking online and real-time

9. GGF11 Naked Keys9 General Certificate Operation  leaves certificates with the market segments:  impossible to justify own business process and/or online access  no-value operations  with no-value market segment, difficult to justify high price certificates  without independent certification revenue flow for certificates, difficult to operate high integrity operation  without high integrity operation, it is impossible to justify use of certificates for anything other than no-value operations

10. GGF11 Naked Keys10 Trusted 3rd Party Operation  Typically violates basic business principles  contract/payment between key-owner and certification authority  contract/payment between key-owner and relying-party  no contract/payment between relying-party and certification authority  w/o contract/payment, no business obligation

11. GGF11 Naked Keys11 One Of The Certificate Justifications  turn-on non-repudiation bit in the certificate  consumers are con'ed into buying their own certificates  consumers are con'ed into signing transactions and appending certificates with non-repudiation  merchants are incented to install public key infrastructure based on non-repudiation bit shifting burden of proof in disputes from merchants to consumers  cal. and federal e-sign law  for real signatures, it is required to demonstrate intention and/or agreement; not simple authentication  using digital signature for simple authentication may actually compromise its use as real signature

12. GGF11 Naked Keys12 Some Real Public Key Issues  public key can replace recording of identity and/or other shared- secret information as part of integrated business process  hijacking institutional authentication files no longer represents fraud exposure because criminals can't use the information to impersonate  digital signature can be used for "something you have" authentication  file containing unique private key  hardware token containing unique private key  issues with certificate complexity have obfuscated real business process authentication trust issues  certification of "something you have" private key container may be used to imply "something you know" authentication (two-factor authentication)  What is the signature environment, is it simple authentication or is there requirement to prove intent and/or agreement

13. GGF11 Naked Keys13 Some Real Public Key Issues  digital signatures on random challenge/response data for simple authentication can compromise its use for signing documents.  Possible to show that private key may have digitally signed random data that was actually a document. Therefor have defense that while digital signature is correct, person may not have actually agreed to the contents of the document.

14. GGF11 Naked Keys14 Some Real Public Key Issues  If there is pin-entry, is there exposure to key-logger  EU “finread” standard specifies certified self-contained reader, display, key-entry not subject to  How does the relying party know that a device meeting finread standard has been used  Certification of personal hardware tokens performing digital signatures (no certificate required)  Certification of digital signature signing environments (like finread) which must also sign transaction as proof to relying-party  Instead of obfuscation and FUD introduced by certificates, look at important trust issues for the relying-party.  Can all the components involved represent trust for $10million transaction or only a $10 transaction.

15. GGF11 Naked Keys15 Legal Signature Requirement  Digital Signature authenticates origin  Legal requirements need to show intention  Backend can request user to re-enter PIN or biometric for new message signing  tokens reliably report that physical action has taken place  Human physical action taken as supporting evidence for intention. © 2002 First azurite LLC. All Rights Reserved.