📄 rfc2692.txt
字号:
Network Working Group C. EllisonRequest for Comments: 2692 IntelCategory: Experimental September 1999 SPKI RequirementsStatus of this Memo This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved.Abstract The IETF Simple Public Key Infrastructure [SPKI] Working Group is tasked with producing a certificate structure and operating procedure to meet the needs of the Internet community for trust management in as easy, simple and extensible a way as possible. The SPKI Working Group first established a list of things one might want to do with certificates (attached at the end of this document), and then summarized that list of desires into requirements. This document presents that summary of requirements.Table of Contents Charter of the SPKI working group................................2 Background.......................................................2 General Requirements.............................................3 Validity and CRLs................................................4 Implementation of Certificates...................................4 List of Certificate Uses.........................................5 Open Questions..................................................11 References......................................................12 Security Considerations.........................................12 Author's Address................................................13 Full Copyright Statement........................................14Ellison Experimental [Page 1] RFC 2692 SPKI Requirements September 1999Charter of the SPKI working group Many Internet protocols and applications which use the Internet employ public key technology for security purposes and require a public key infrastructure to manage public keys. The task of the working group will be to develop Internet standards for an IETF sponsored public key certificate format, associated signature and other formats, and key acquisition protocols. The key certificate format and associated protocols are to be simple to understand, implement, and use. For purposes of the working group, the resulting formats and protocols are to be known as the Simple Public Key Infrastructure, or SPKI. The SPKI is intended to provide mechanisms to support security in a wide range of Internet applications, including IPSEC protocols, encrypted electronic mail and WWW documents, payment protocols, and any other application which will require the use of public key certificates and the ability to access them. It is intended that the Simple Public Key Infrastructure will support a range of trust models.Background The term certificate traces back to the MIT bachelor's thesis of Loren M. Kohnfelder [KOHN]. Kohnfelder, in turn, was responding to a suggestion by Diffie and Hellman in their seminal paper [DH]. Diffie and Hellman noted that with public key cryptography, one no longer needs a secure channel over which to transmit secret keys between communicants. Instead, they suggested, one can publish a modified telephone book -- one with public keys in place of telephone numbers. One could then look up his or her desired communication partner in the directory, find that person's public key and open a secure channel to that person. Kohnfelder took that suggestion and noted that an on-line service has the disadvantage of being a performance bottleneck. To replace it, he proposed creation of digitally signed directory entries which he called certificates. In the time since 1978, the term certificate has frequently been assumed to mean a binding between name and key. The SPKI team directly addressed the issue of <name,key> bindings and realized that such certificates are of extremely limited use for trust management. A keyholder's name is one attribute of the keyholder, but as can be seen in the list of needs in this document, a person's name is rarely of security interest. A user of a certificate needs to know whether a given keyholder has been granted some specific authorization.Ellison Experimental [Page 2] RFC 2692 SPKI Requirements September 1999General Requirements We define the term KEYHOLDER of a public key to refer to the person or other entity that controls the corresponding private key. The main purpose of an SPKI certificate is to authorize some action, give permission, grant a capability, etc. to or for a keyholder. The keyholder is most directly identified by the public key itself, although for convenience or other purposes some indirection (delayed binding) may be employed. That indirection can be via a collision- free hash of the public key or via a name, later to be resolved into a key. The definition of attributes or authorizations in a certificate is up to the author of code which uses the certificate. The creation of new authorizations should not require interaction with any other person or organization but rather be under the total control of the author of the code using the certificate. Because SPKI certificates might carry information that the keyholder might not want to publish, we assume that certificates will be distributed directly by the keyholder to the verifier. If the keyholder wishes to use a global repository, such as LDAP, the global PGP key server or the DNS database, that is up to the keyholder and not for the SPKI WG to specify. Because SPKI certificates will carry information that, taken together over all certificates, might constitute a dossier and therefore a privacy violation, each SPKI certificate should carry the minimum information necessary to get a job done. The SPKI certificate is then to be like a single key rather than a key ring or a single credit card rather than a whole wallet. The keyholder should be able to release a minimum of information in order to prove his or her permission to act. It is necessary for at least some certificates to be anonymous. Because one use of SPKI certificates is in secret balloting and similar applications, an SPKI certificate must be able to assign an attribute to a blinded signature key. One attribute of a keyholder is a name. There are names the keyholder prefers to be called and there are names by which the keyholder is known to various other keyholders. An SPKI certificate must be able to bind a key to such names. The SDSI work of Rivest and Lampson has done an especially good job of defining and using local name spaces, therefore if possible SPKI should support the SDSIEllison Experimental [Page 3] RFC 2692 SPKI Requirements September 1999 name construct. [Note: SPKI and SDSI have merged.]Validity and CRLs An SPKI certificate, like any other, should be able to carry a validity period: dates within which it is valid. It may also be necessary to have on-line refinement of validity. This is frequently achieved via a Certificate Revocation List (CRL) in previous certificate designs. A minimal CRL contains a list of revoked certificates, identified uniquely, a sequence number and a signature. Its method of transmission is not specified. If it encounters some certificate that it lists, then it annihilates that certificate. If it encounters a previous CRL, as indicated by sequence number, then it annihilates that previous CRL. Such a CRL leads to non-deterministic program behavior. Therefore, we take as a requirement that if SPKI uses CRLs, then the certificate that uses it must explicitly tell the verifier where to find the CRL, the CRL must carry explicit validity dates and the dates of a sequence of CRLs must not overlap. Under this set of requirements, behavior of certificate validation is deterministic (aside from the question of clock skew). A CRL is a negative statement. It is the digital equivalent of the little paper books of bad checks or bad credit cards that were distributed to cashiers in the 1970's and before. These have been replaced in the retail world by positive statements -- on-line validation of a single check, ATM card or credit card. SPKI should support both positive and negative on-line validations. Any CRL or revalidation instrument must have its own lifetime. A lifetime of 0 is not possible because of communication delays and clock skews, although one can consider an instrument whose lifetime is "one use" and which is delivered only as part of a challenge/response protocol.Implementation of Certificates The authorization certificates that are envisioned for SPKI (and needed to meet the demands of the list given at the end of this document) should be generated by any keyholder empowered to grant or delegate the authorization in question. The code to generate certificates should be written by many different developers, frequently persons acting alone, operating out of garages or dorm rooms. This leads to a number of constraints on the structure and encoding of certificates. In addition, SPKI certificates should be usable in very constrained environments, such as smart cards or smallEllison Experimental [Page 4] RFC 2692 SPKI Requirements September 1999 embedded systems. The code to process them and the memory to store them should both be as small as possible. An SPKI certificate should be as simple as possible. There should be a bare minimum of fields necessary to get the job done and there should be an absolute minimum of optional fields. In particular, the structure should be specific enough that the creator of a certificate is constrained by the structure definition, not by complaints (or error messages) from the reader of a certificate. An SPKI certificate should be described in as simple a method as possible, relating directly to the kind of structures a C or PASCAL programmer would normally write. No library code should be required for the packing or parsing of SPKI certificates. In particular, ASN.1 is not to be used. A certificate should be signed exactly as it is transmitted. There should be no reformatting called for in the process of checking a certificate's signature (although one might canonicalize white space during certificate input, for example, if the format is text). For efficiency, if possible, an SPKI certificate should be encoded in an LR(0) grammar. That is, neither packing nor parsing of the structure should require a scan of the data. Data should be read into the kind of structure a programmer would want to use without touching the incoming bytes more than once. For efficiency, if possible, an SPKI certificate should be packed and parsed without any recursion.List of Certificate Uses The list below is a brainstorming list, accumulated on the SPKI mailing list, of uses of such certificates. - I need a certificate to give me permission to write electronic checks. - My bank would need a certificate, proving to others that it is a bank capable of cashing electronic checks and permitted to give permission to people to write electronic checks.Ellison Experimental [Page 5] RFC 2692 SPKI Requirements September 1999 - My bank would issue a certificate signing the key of a master bank certifier -- perhaps NACHA -- so that I could follow a certificate chain from a key I know (my bank's) to the key of any other bank in the US and, similarly, to any other bank in the world. - I might generate a certificate (a "reputation voucher") for a friend to introduce him to another friend -- in which certificate I could testify to my friend's political opinion (e.g., libertarian cypherpunk) or physical characteristics or anything else of interest. - I might have a certificate giving my security clearance, signed by a governmental issuing authority. - I want a certificate for some software I have downloaded and am considering running on my computer -- to make sure it hasn't changed and that some reputable company or person stands behind it. - I need certificates to bind names to public keys: - [traditional certificate] binding a key to a name, implying "all the attributes of the real person having this name are transferred to this key by this certificate". This requires unique identification of a person (which is difficult in non-digital space, as it is) and someone trustworthy binding that unique name to the key in question. In this model, a key starts out naked and acquires attributes, permissions and authority from the person bound to it. - [direct certificate] binding a name to a key, implying "I (the person who is able to use the associated private key to make this signature) declare that I go by the name of XXXXXXX." The unique identification of the key is automatic -- from the key itself or a cryptographic hash of the key. The binding is done by the key itself -- in a self-signed certificate. In this model, a key is loaded with attributes, permissions and authority directly by other certificates, not indirectly through some person's name, and this certificate declares only a name or nickname by which the key's owner likes to be addressed. - [personal binding] binding a key to a nickname. This kind of certificate is signed by me, singing someone else's key and binding it to a nickname by which I know that person. It is for my use only -- never given out -- and is a signed certificate to prevent tampering with my own privateEllison Experimental [Page 6] RFC 2692 SPKI Requirements September 1999 directory of keys. It says nothing about how I certified the binding to my own satisfaction between the key and my friend. - I might be doing genealogy and be collecting what amounts to 3x5 cards with facts to be linked together. Some of these links would be from one content to another reference [e.g., indexing and cross-referencing]. Others might be links to the researcher who collected the fact. By rights, the fact should be signed by that researcher. Viewing only the signature on the fact and the link to the researcher, this electronic 3x5 card becomes a certificate. - I want to sign a contract to buy a house. What kind of certificate do I need? - I have found someone on the net and she sounds really nice. Things are leading up to cybersex. How do I make sure she's not really some 80-year-old man in a nursing home? - I have met someone on the net and would like a picture of her and her height, weight and other measurements from a trustworthy source. - Can I have a digital marriage license? - Can I have a digital divorce decree? - ..a digital Voter Registration Card? - There are a number of cards one carries in a typical wallet which could become certificates attached to a public key: - health insurance card - prescription drug card - driver's license (for permission to drive) - driver's license (for permission to buy alcohol) - supermarket discount card - supermarket check-cashing card [I know -- anachronism] - Blockbuster Video rental card - ATM cardEllison Experimental [Page 7]⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -