rfc2692.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.


RFC 2692                   SPKI Requirements              September 1999


      -  Credit card

      -  membership card in the ACLU, NRA, Republican party, Operation
         Rescue, NARAL, ACM, IEEE, ICAR....

      -  Red Cross blood donor card

      -  Starbuck's Coffee buy-10-get-1-free card

      -  DC Metro fare card

      -  Phone calling card

      -  Alumni Association card

      -  REI Membership card

      -  Car insurance card

      -  claim check for a suitcase

      -  claim check for a pawned radio

      -  authorization for followup visits to a doctor, after surgery

      -  Better Business Bureau [BBB] style reputation certificates
         [testimonies from satisfied customers]

      -  BBB-style certificate that no complaints exist against a
         business or doctor or dentist, etc.

      -  LDS Temple Recommend

      -  Stock certificate

      -  Stock option

      -  Car title

      -  deed to land

      -  proof of ownership of electronic equipment with an ID number

      -  time card certificate [activating a digital time clock]

      -  proof of degree earned [PhD, LLD, MD, ...]

      -  permission to write digitally signed prescriptions for drugs



Ellison                       Experimental                      [Page 8]

RFC 2692                   SPKI Requirements              September 1999


      -  permission to spend up to $X of a company's money

      -  permission to issue nuclear launch codes

      -  I'm a sysadmin, I want to carry a certificate, signed by SAGE,
         that says I'm good at the things sysadmins are good at.

      -  I'm that same sysadmin, I want an ephemeral certificate that
         grants me root access to certain systems for the day, or the
         week, or...

         Certain applications *will* want some form of auditing, but the
         audit identity should be in the domain of the particular
         application...  For instance an "is a system administrator of
         this host" certificate would probably want to include an audit
         identity, so you can figure out which of your multiple admins
         screwed something up.

      -  I'm an amateur radio operator.  I want a signed certificate
         that says I'm allowed to engage in amateur radio, issued by the
         DOC.  [I currently have a paper version of one].  This would be
         useful in enforcing access policies to the amateur spectrum;
         and in tracking abuse of that same spectrum.  Heck!  extend
         this concept to all licensed spectrum users.

      -  I'm the a purchasing agent for a large corporation.  I want to
         posses a certificate that tells our suppliers that I'm
         authorized to make purchases up to $15,000.  I don't want the
         suppliers to know my name, lest their sales people bug me too
         much.  I don't want to have to share a single "Megacorp
         Purchasing Department Certificate" with others doing the same
         job [the private key would need to be shared--yuck!].

      -  "This signed-key should be considered equivalent to the
         certifying-key until this certificate expires for the following
         purposes ..."
            [This is desirable when you wish to reduce the exposure of
            long-term keys.  One way to do this is to use smart cards,
            but those typically have slow processors and are connected
            through low-bandwidth links; however, if you only use the
            smart card at "login" time to certify a short-term key pair,
            you get high performance and low exposure of the long term
            key.








Ellison                       Experimental                      [Page 9]

RFC 2692                   SPKI Requirements              September 1999


            I'll note here that this flies in the face of attempts to
            prevent delegation of certain rights.  Maybe we need a
            "delegation-allowed" bit -- but there's nothing to stop
            someone who wishes to delegate against the rules from also
            loaning out their private key.].

      -  "I am the current legitimate owner of a particular chunk of
         Internet address space."
            [I'd like to see IPSEC eventually become usable, at least
            for privacy, without need for prior arrangement between
            sites, but I think there's a need for a "I own this
            address"/"I own this address range" certificate in order for
            IPSEC to coexist with existing ip-address-based firewalls.]

      -  "I am the current legitimate owner of a this DNS name or
         subtree."

      -  "I am the legitimate receiver of mail sent to this rfc822 email
         address.  [this might need to be signed by a key which itself
         had been certified by the appropriate "DNS name owner"
         certificate]."
            [This is in case I know someone owns a particular e-mail
            address but I don't know their key.]

      -  Encryption keys for E-mail and file encryption

      -  Authentication of people or other entities

      -  Digital signatures (unforgeability)

      -  Timestamping / notary services

      -  Host authentication

      -  Service authentication

         Other requirements:

         -  Trust model must be a web (people want to choose whom they
            trust).  People must be able to choose whom they trust or
            consider reliable roots (maybe with varying reliabilities).

         -  Some applications (e.g., notary services) require highly
            trusted keys; generation complexity is not an issue here.

         -  Some applications (e.g., host authentication) require
            extremely light (or no) bureaucracy.  Even communication
            with the central administrator may be a problem.



Ellison                       Experimental                     [Page 10]

RFC 2692                   SPKI Requirements              September 1999


         -  Especially in lower-end applications (e.g. host
            authentication) the people generating the keys (e.g.,
            administrators) will change, and you will no longer want
            them to be able to certify.  On the other hand, you will
            usually also not want all keys they have generated to
            expire.  This may imply a "certification right expiration"
            certificate requirement, probably to be implemented together
            with notary services.

         -  Keys will need to be cached locally to avoid long delays
            fetching frequently used keys.  Cf. current name servers.
            The key infrastructure may in future get used almost as
            often as the name server.  The caching and performance
            requirements are similar.

         -  Reliable distribution of key revocations and other
            certificates (e.g., the ceasing of the right to make new
            certificates).  May involve goals like "will have spread
            everywhere in 24 hours" or something like that.  This
            interacts with caching.

Open Questions

   Given such certificates, there remain some questions, most to do with
   proofs of the opposite of what a certificate is designed to do.
   These do not have answers provided by certificate definition or
   issuing alone.

   -  Someone digitally signs a threatening e-mail message with my
      private key and sends it to [e-mail].  How do I
      prove that I didn't compose and send the message?  What kind of
      certificate characteristic might help me in this?

         This is an issue of (non-)repudiation and therefore a matter of
         private key protection.  Although this is of interest to the
         user of certificates, certificate format, contents or issuing
         machinery can not ensure the protection of a user's private key
         or prove whether or not a private key has been stolen or
         misused.

   -  Can certificates help do a title scan for purchase of a house?

         Certificates might be employed to carry information in a
         tamper-proof way, but building the database necessary to record
         all house titles and all liens is a project not related to
         certificate structure.





Ellison                       Experimental                     [Page 11]

RFC 2692                   SPKI Requirements              September 1999


   -  Can a certificate be issued to guarantee that I am not already
      married, so that I can then get a digital marriage license?

         The absence of attributes can be determined only if all
         relevant records are digitized and all parties have inescapable
         IDs.  The former is not likely to happen in our lifetimes and
         the latter receives political resistance.

         A certificate can communicate the 'positive' attribute "not
         already married" or "not registered as a voter in any other
         district".  That assumes that some organization is capable of
         determining that fact for a given keyholder.  The method of
         determining such a negative fact is not part of the certificate
         definition.

   -  The assumption in most certificates is that the proper user will
      protect his private key very well, to prevent anyone else from
      accessing his funds.  However, in some cases the certificate
      itself might have monetary value [permission to prescribe drugs,
      permission to buy alcohol, ...].  What is to prevent the holder of
      such a certificate from loaning out his private key?

         This is a potential flaw in any system providing authorization
         and an interesting topic for study.  What prevents a doctor or
         dentist from selling prescriptions for controlled substances to
         drug abusers?

References

   [DH]   Diffie and Hellman, "New Directions in Cryptography", IEEE
          Transactions on Information Theory IT-22, 6 (Nov. 1976), 644-
          654.

   [KOHN] Loren Kohnfelder, "Towards a Practical Public-key
          Cryptosystem", Bachelor's thesis, MIT, May, 1978.

Security Considerations

   Security issues are discussed throughout this memo.












Ellison                       Experimental                     [Page 12]

RFC 2692                   SPKI Requirements              September 1999


Author's Address

   Carl M. Ellison
   Intel Corporation
   2111 NE 25th Ave   M/S JF3-212
   Hillsboro OR 97124-5961 USA

   Phone: [phone]
   Fax:   [phone]
   EMail: [e-mail]
          [e-mail]
   Web:   http://www.pobox.com/~cme







































Ellison                       Experimental                     [Page 13]

RFC 2692                   SPKI Requirements              September 1999


Full Copyright Statement

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Ellison                       Experimental                     [Page 14]