Network Working Group C. Ellison
Request for Comments: 2692 Intel
Category: Experimental September 1999
Network Working Group C. Ellison
Request for Comments: 2692 Intel
Category: Experimental September 1999
SPKI Requirements
SPKI要求
Status 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.
版权所有（C）互联网协会（1999年）。版权所有。
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.
IETF简单公钥基础设施[SPKI]工作组的任务是生成一个证书结构和操作程序，以尽可能简单和可扩展的方式满足互联网社区对信任管理的需求。
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.
SPKI工作组首先建立了一个清单，列出了人们可能希望使用证书做的事情（附在本文件末尾），然后将该清单汇总到需求中。本文件介绍了该需求概要。
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........................................14
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........................................14
Charter of the SPKI working group
SPKI工作组章程
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.
许多使用Internet的Internet协议和应用程序出于安全目的采用公钥技术，并需要公钥基础设施来管理公钥。
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.
工作组的任务是为IETF赞助的公钥证书格式、相关签名和其他格式以及密钥获取协议制定互联网标准。密钥证书格式和相关协议应易于理解、实现和使用。为了工作组的目的，产生的格式和协议被称为简单公钥基础设施，或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.
SPKI旨在提供各种机制，以支持各种互联网应用中的安全性，包括IPSEC协议、加密电子邮件和WWW文档、支付协议以及需要使用公钥证书并能够访问它们的任何其他应用。简单的公钥基础设施将支持一系列信任模型。
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.
证书一词可以追溯到麻省理工学院Loren M.Kohnfeld[KOHN]的学士学位论文。科恩费尔德反过来回应了迪菲和赫尔曼在他们的开创性论文[DH]中的建议。Diffie和Hellman指出，使用公钥加密技术，人们不再需要在通信者之间传输密钥的安全通道。相反，他们建议，人们可以出版一本经过修改的电话簿——用公钥代替电话号码。然后可以在目录中查找他或她想要的通信伙伴，找到此人的公钥，并为此人打开一个安全通道。Kohnfeld接受了这一建议，并指出在线服务的缺点是成为性能瓶颈。为了取而代之，他建议创建数字签名的目录条目，他称之为证书。自1978年以来，术语证书经常被认为是指名称和密钥之间的绑定。
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.
SPKI团队直接解决了<name，key>绑定问题，并意识到此类证书在信任管理中的用途极其有限。钥匙持有人的姓名是钥匙持有人的一个属性，但从本文件的需求列表中可以看出，一个人的姓名很少具有担保权益。证书的用户需要知道给定的密钥持有者是否已被授予某种特定授权。
General 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.
SPKI证书的主要目的是授权某些操作、给予许可、授予密钥持有者能力等。
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.
因为SPKI证书可能包含密钥持有者可能不想发布的信息，所以我们假设证书将由密钥持有者直接分发给验证器。如果密钥持有人希望使用全局存储库，如LDAP、全局PGP密钥服务器或DNS数据库，则由密钥持有人决定，而不是由SPKI WG指定。
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.
由于SPKI证书将包含所有证书中可能构成档案的信息，因此可能会侵犯隐私，因此每个SPKI证书应包含完成工作所需的最低信息。然后，SPKI证书就像一把钥匙而不是钥匙圈，或者像一张信用卡而不是整个钱包。钥匙持有人应能够发布最少的信息，以证明其行为许可。
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.
由于SPKI证书的一种用途是在无记名投票和类似应用程序中使用，因此SPKI证书必须能够为盲签名密钥分配属性。
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 SDSI
密钥持有者的一个属性是名称。有一些名字是钥匙持有人更喜欢被称呼的，也有一些名字是其他钥匙持有人所知道的。SPKI证书必须能够将密钥绑定到此类名称。Rivest和Lampson的SDSI工作在定义和使用本地名称空间方面做得特别好，因此如果可能，SPKI应该支持SDSI
name construct. [Note: SPKI and SDSI have merged.]
名称构造。[注：SPKI和SDSI已合并。]
Validity and CRLs
有效性与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.
SPKI证书和其他证书一样，应该能够携带一个有效期：它的有效日期。可能还需要在线改进有效性。这通常是通过以前的证书设计中的证书撤销列表（CRL）实现的。
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).
最小CRL包含唯一标识的已吊销证书列表、序列号和签名。未规定其传输方法。如果它遇到它列出的某个证书，那么它将销毁该证书。如果它遇到一个先前的CRL，如序列号所示，那么它将消除该先前的CRL。这样的CRL会导致程序行为的不确定性。因此，我们要求，如果SPKI使用CRL，那么使用它的证书必须明确告诉验证者在哪里找到CRL，CRL必须带有明确的有效日期，并且CRL序列的日期不得重叠。在这组需求下，证书验证的行为是确定性的（除了时钟偏移的问题）。
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.
CRL是一种否定的陈述。它在数字上相当于20世纪70年代及以前分发给收银员的坏支票或坏信用卡的小纸簿。在零售业，这些已经被积极的声明所取代——在线验证一张支票、ATM卡或信用卡。
SPKI should support both positive and negative on-line validations.
SPKI应支持正面和负面在线验证。
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.
任何CRL或再验证仪器必须有其自身的使用寿命。0的寿命是不可能的，因为通信延迟和时钟偏移，尽管人们可以考虑一种仪器，其寿命是“一次使用”，它仅作为挑战/响应协议的一部分被交付。
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 small
为SPKI设想的授权证书（以及满足本文件末尾给出的列表要求所需的授权证书）应由任何有权授予或委托相关授权的密钥持有人生成。生成证书的代码应该由许多不同的开发人员编写，通常是在车库或宿舍外单独操作的人员。这导致对证书的结构和编码有许多限制。此外，SPKI证书应该可以在非常受限的环境中使用，例如智能卡或小型计算机
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.
SPKI证书应尽可能简单。完成工作所需的字段应该是最小的，可选字段应该是绝对最小的。特别是，结构应该足够具体，以使证书的创建者受到结构定义的约束，而不是受到来自证书读取器的投诉（或错误消息）的约束。
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.
SPKI证书应该用尽可能简单的方法描述，与C或PASCAL程序员通常编写的结构类型直接相关。
No library code should be required for the packing or parsing of SPKI certificates. In particular, ASN.1 is not to be used.
打包或解析SPKI证书不需要库代码。特别是，不使用ASN.1。
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.
为了提高效率，如果可能的话，SPKI证书应该用LR（0）语法编码。也就是说，结构的打包或解析都不需要扫描数据。数据应该读入程序员希望使用的结构中，而不必多次接触传入的字节。
For efficiency, if possible, an SPKI certificate should be packed and parsed without any recursion.
为了提高效率，如果可能的话，应该打包和解析SPKI证书，而不进行任何递归。
List of Certificate Uses
证书使用清单
The list below is a brainstorming list, accumulated on the SPKI mailing list, of uses of such certificates.
下面的列表是一份集思广益的列表，在SPKI邮件列表中积累了此类证书的使用情况。
- 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.
- 我的银行需要一份证书，向其他人证明它是一家能够兑现电子支票的银行，并且允许人们写电子支票。
- 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.
- 我的银行会签发一份证书，对主银行认证机构（可能是NACHA）的密钥进行签名，这样我就可以遵循一个证书链，从我知道的密钥（我的银行的）到美国任何其他银行的密钥，同样地，到世界上任何其他银行的密钥。
- 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.
- 我可能会为一位朋友生成一份证书（“声誉凭证”），将他介绍给另一位朋友——在该证书中，我可以证明我朋友的政治观点（例如，自由主义的cypherpunk）或身体特征或任何其他感兴趣的东西。
- 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.
- [traditional certificate]将密钥绑定到名称，这意味着“拥有此名称的真实人的所有属性都通过此证书转移到该密钥”。这需要一个人的唯一身份（这在非数字空间中是很困难的），并且需要一个可靠的人将这个唯一的名字绑定到相关的密钥上。在这个模型中，密钥从裸体开始，从绑定到它的人那里获取属性、权限和权限。
- [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.
- [直接证书]将名称绑定到密钥，这意味着“我（能够使用相关私钥进行签名的人）声明我的名字是XXXXXXX。”密钥的唯一标识是自动的——来自密钥本身或密钥的加密散列。绑定由密钥本身完成——在自签名证书中。在这个模型中，密钥由其他证书直接加载属性、权限和权限，而不是通过某人的姓名间接加载，并且该证书仅声明密钥所有者希望使用的名称或昵称。
- [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 private
- [个人绑定]将密钥绑定到昵称。这种证书是由我签署的，唱着别人的密钥，并将其绑定到我认识那个人的昵称上。它只供我使用——从未分发过——是一个签名证书，用于防止篡改我自己的私人证书
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.
- 我可能在做家谱，收集3x5张卡片，将事实联系在一起。其中一些链接可能是从一个内容到另一个引用[例如，索引和交叉引用]。其他可能是收集事实的研究人员的链接。根据权利，事实应该由研究人员签字。仅查看事实上的签名和与研究人员的链接，此3x5电子卡即成为证书。
- 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?
- 我在网上找到了一个人，她听起来很不错。事情正在走向网络性爱。我怎样才能确定她不是一个真正的80岁老人？
- 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 card
- ATM卡
- Credit card
- 信用卡
- membership card in the ACLU, NRA, Republican party, Operation Rescue, NARAL, ACM, IEEE, ICAR....
- ACLU、NRA、共和党、救援行动、NARAL、ACM、IEEE、ICAR……的会员卡。。。。
- Red Cross blood donor card
- 红十字会献血卡
- Starbuck's Coffee buy-10-get-1-free card
- 星巴克咖啡“买10送1”卡
- DC Metro fare card
- DC地铁票价卡
- Phone calling card
- 电话卡
- Alumni Association card
- 校友会会员卡
- REI Membership card
- REI会员卡
- 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]
- Better Business Bureau[BBB]风格的声誉证书[来自满意客户的证词]
- BBB-style certificate that no complaints exist against a business or doctor or dentist, etc.
- BBB类型的证书，证明不存在对企业、医生或牙医等的投诉。
- LDS Temple Recommend
- LDS寺庙推荐
- Stock certificate
- 股票
- Stock option
- 股票期权
- Car title
- 汽车所有权
- deed to land
- 土地契约
- proof of ownership of electronic equipment with an ID number
- 具有ID号的电子设备所有权证明
- time card certificate [activating a digital time clock]
- 时间卡证书[激活数字时钟]
- proof of degree earned [PhD, LLD, MD, ...]
- 获得学位证明[博士、法学博士、医学博士，…]
- permission to write digitally signed prescriptions for drugs
- 允许为药品开具数字签名处方
- permission to spend up to $X of a company's money
- 允许花费最多X美元的公司资金
- 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.
- 我是一名系统管理员，我想携带一份由SAGE签署的证书，上面写着我擅长系统管理员擅长的事情。
- 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...
- 我是同一个系统管理员，我想要一个临时证书，授予我在某一天、某一周或某一天对某些系统的root访问权限，或者。。。
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!].
- 我是一家大公司的采购代理。我想拥有一份证书，告诉我们的供应商我有权购买高达15000美元的商品。我不想让供应商知道我的名字，以免他们的销售人员太烦我。我不想与其他做同样工作的人共享一份“Megacorp采购部门证书”[私钥需要共享--真恶心！]。
- "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.
- “出于以下目的，在证书到期之前，此签名密钥应被视为等同于认证密钥…”[当您希望减少长期钥匙的暴露时，这是可取的。一种方法是使用智能卡，但这些卡通常具有较慢的处理器，并且通过低带宽链路连接；但是，如果您仅在“登录”时使用智能卡认证短期密钥对的时间到了，您可以获得高性能和低风险的长期密钥。
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.]
- “我目前是一块特定Internet地址空间的合法所有者。”[我希望看到IPSEC最终变得可用，至少出于隐私，而无需事先在站点之间进行安排，但我认为需要“我拥有此地址”/“我拥有此地址范围”证书，以便IPSEC与现有的基于ip地址的防火墙共存。]
- "I am the current legitimate owner of a this DNS name or subtree."
- “我是此DNS名称或子树的当前合法所有者。”
- "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.]
- “我是发送到此rfc822电子邮件地址的邮件的合法接收者。[这可能需要由一个密钥签名，该密钥本身已由相应的“DNS名称所有者”证书认证]。”[在这种情况下，我知道有人拥有特定的电子邮件地址，但我不知道他们的密钥。]
- 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.
- 某些应用程序（例如，主机身份验证）需要非常轻（或不需要）的官僚作风。甚至与中央管理员的通信也可能是一个问题。
- 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.
- 密钥撤销和其他证书的可靠分发（例如，停止制作新证书的权利）。可能会涉及诸如“24小时内会扩散到所有地方”之类的目标。这与缓存交互。
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 president@whitehouse.gov. How do I prove that I didn't compose and send the message? What kind of certificate characteristic might help me in this?
- 有人用我的私钥对具有威胁性的电子邮件进行数字签名，并将其发送到president@whitehouse.gov. 我如何证明我没有撰写并发送邮件？什么样的证书特征可以在这方面帮助我？
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.
证书可以用来以防篡改的方式携带信息，但建立记录所有房屋所有权和所有留置权所需的数据库是一个与证书结构无关的项目。
- 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.
只有当所有相关记录都数字化并且各方都有不可避免的ID时，才能确定属性的缺失。前者不太可能在我们有生之年发生，而后者受到政治抵制。
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.
[DH]Diffie和Hellman，“密码学的新方向”，IEEE信息论交易IT-22，6（1976年11月），644-654。
[KOHN] Loren Kohnfelder, "Towards a Practical Public-key Cryptosystem", Bachelor's thesis, MIT, May, 1978.
[KOHN]Loren Kohnfeld，“走向实用的公钥密码系统”，学士学位论文，麻省理工学院，1978年5月。
Security Considerations
安全考虑
Security issues are discussed throughout this memo.
本备忘录中讨论了安全问题。
Author's Address
作者地址
Carl M. Ellison Intel Corporation 2111 NE 25th Ave M/S JF3-212 Hillsboro OR 97124-5961 USA
卡尔·M·埃里森英特尔公司2111东北25大街M/S JF3-212希尔斯博罗或97124-5961美国
Phone: +1-503-264-2900
Fax: +1-503-264-6225
EMail: carl.m.ellison@intel.com
cme@alum.mit.edu
Web: http://www.pobox.com/~cme
Phone: +1-503-264-2900
Fax: +1-503-264-6225
EMail: carl.m.ellison@intel.com
cme@alum.mit.edu
Web: http://www.pobox.com/~cme
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
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.
RFC编辑功能的资金目前由互联网协会提供。