Network Working Group C. Ellison
Request for Comments: 2693 Intel
Category: Experimental B. Frantz
Electric Communities
B. Lampson
Microsoft
R. Rivest
MIT Laboratory for Computer Science
B. Thomas
Southwestern Bell
T. Ylonen
SSH
September 1999
Network Working Group C. Ellison
Request for Comments: 2693 Intel
Category: Experimental B. Frantz
Electric Communities
B. Lampson
Microsoft
R. Rivest
MIT Laboratory for Computer Science
B. Thomas
Southwestern Bell
T. Ylonen
SSH
September 1999
SPKI Certificate Theory
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 SPKI Working Group has developed a standard form for digital certificates whose main purpose is authorization rather than authentication. These structures bind either names or explicit authorizations to keys or other objects. The binding to a key can be directly to an explicit key, or indirectly through the hash of the key or a name for it. The name and authorization structures can be used separately or together. We use S-expressions as the standard format for these certificates and define a canonical form for those S-expressions. As part of this development, a mechanism for deriving authorization decisions from a mixture of certificate types was developed and is presented in this document.
SPKI工作组为数字证书开发了一种标准格式，其主要目的是授权而不是认证。这些结构将名称或显式授权绑定到密钥或其他对象。对键的绑定可以直接绑定到显式键，也可以通过该键或其名称的哈希间接绑定到该键。名称和授权结构可以单独使用，也可以一起使用。我们使用S表达式作为这些证书的标准格式，并为这些S表达式定义一个规范形式。作为该开发的一部分，开发了一种从证书类型的混合中得出授权决策的机制，并在本文档中介绍。
This document gives the theory behind SPKI certificates and ACLs without going into technical detail about those structures or their uses.
本文档给出了SPKI证书和ACL背后的理论，而没有涉及这些结构或其用途的技术细节。
Table of Contents
目录
1. Overview of Contents.......................................3
1.1 Glossary..................................................4
2. Name Certification.........................................5
2.1 First Definition of CERTIFICATE...........................6
2.2 The X.500 Plan and X.509..................................6
2.3 X.509, PEM and PGP........................................7
2.4 Rethinking Global Names...................................7
2.5 Inescapable Identifiers...................................9
2.6 Local Names..............................................10
2.6.1 Basic SDSI Names.......................................10
2.6.2 Compound SDSI Names....................................10
2.7 Sources of Global Identifiers............................11
2.8 Fully Qualified SDSI Names...............................11
2.9 Fully Qualified X.509 Names..............................12
2.10 Group Names.............................................12
3. Authorization.............................................12
3.1 Attribute Certificates...................................13
3.2 X.509v3 Extensions.......................................13
3.3 SPKI Certificates........................................14
3.4 ACL Entries..............................................15
4. Delegation................................................15
4.1 Depth of Delegation......................................15
4.1.1 No control.............................................15
4.1.2 Boolean control........................................16
4.1.3 Integer control........................................16
4.1.4 The choice: boolean....................................16
4.2 May a Delegator Also Exercise the Permission?............17
4.3 Delegation of Authorization vs. ACLs.....................17
5. Validity Conditions.......................................18
5.1 Anti-matter CRLs.........................................18
5.2 Timed CRLs...............................................19
5.3 Timed Revalidations......................................20
5.4 Setting the Validity Interval............................20
5.5 One-time Revalidations...................................20
5.6 Short-lived Certificates.................................21
5.7 Other possibilities......................................21
5.7.1 Micali's Inexpensive On-line Results...................21
5.7.2 Rivest's Reversal of the CRL Logic.....................21
6. Tuple Reduction...........................................22
6.1 5-tuple Defined..........................................23
6.2 4-tuple Defined..........................................24
6.3 5-tuple Reduction Rules..................................24
6.3.1 AIntersect.............................................25
6.3.2 VIntersect.............................................27
6.3.3 Threshold Subjects.....................................27
6.3.4 Certificate Path Discovery.............................28
1. Overview of Contents.......................................3
1.1 Glossary..................................................4
2. Name Certification.........................................5
2.1 First Definition of CERTIFICATE...........................6
2.2 The X.500 Plan and X.509..................................6
2.3 X.509, PEM and PGP........................................7
2.4 Rethinking Global Names...................................7
2.5 Inescapable Identifiers...................................9
2.6 Local Names..............................................10
2.6.1 Basic SDSI Names.......................................10
2.6.2 Compound SDSI Names....................................10
2.7 Sources of Global Identifiers............................11
2.8 Fully Qualified SDSI Names...............................11
2.9 Fully Qualified X.509 Names..............................12
2.10 Group Names.............................................12
3. Authorization.............................................12
3.1 Attribute Certificates...................................13
3.2 X.509v3 Extensions.......................................13
3.3 SPKI Certificates........................................14
3.4 ACL Entries..............................................15
4. Delegation................................................15
4.1 Depth of Delegation......................................15
4.1.1 No control.............................................15
4.1.2 Boolean control........................................16
4.1.3 Integer control........................................16
4.1.4 The choice: boolean....................................16
4.2 May a Delegator Also Exercise the Permission?............17
4.3 Delegation of Authorization vs. ACLs.....................17
5. Validity Conditions.......................................18
5.1 Anti-matter CRLs.........................................18
5.2 Timed CRLs...............................................19
5.3 Timed Revalidations......................................20
5.4 Setting the Validity Interval............................20
5.5 One-time Revalidations...................................20
5.6 Short-lived Certificates.................................21
5.7 Other possibilities......................................21
5.7.1 Micali's Inexpensive On-line Results...................21
5.7.2 Rivest's Reversal of the CRL Logic.....................21
6. Tuple Reduction...........................................22
6.1 5-tuple Defined..........................................23
6.2 4-tuple Defined..........................................24
6.3 5-tuple Reduction Rules..................................24
6.3.1 AIntersect.............................................25
6.3.2 VIntersect.............................................27
6.3.3 Threshold Subjects.....................................27
6.3.4 Certificate Path Discovery.............................28
6.4 4-tuple Reduction........................................28
6.4.1 4-tuple Threshold Subject Reduction....................29
6.4.2 4-tuple Validity Intersection..........................29
6.5 Certificate Translation..................................29
6.5.1 X.509v1................................................29
6.5.2 PGP....................................................30
6.5.3 X.509v3................................................30
6.5.4 X9.57..................................................30
6.5.5 SDSI 1.0...............................................30
6.5.6 SPKI...................................................31
6.5.7 SSL....................................................31
6.6 Certificate Result Certificates..........................32
7. Key Management............................................33
7.1 Through Inescapable Names................................33
7.2 Through a Naming Authority...............................33
7.3 Through <name,key> Certificates..........................34
7.4 Increasing Key Lifetimes.................................34
7.5 One Root Per Individual..................................35
7.6 Key Revocation Service...................................36
7.7 Threshold ACL Subjects...................................36
8. Security Considerations...................................37
References...................................................38
Acknowledgments..............................................40
Authors' Addresses...........................................41
Full Copyright Statement.....................................43
6.4 4-tuple Reduction........................................28
6.4.1 4-tuple Threshold Subject Reduction....................29
6.4.2 4-tuple Validity Intersection..........................29
6.5 Certificate Translation..................................29
6.5.1 X.509v1................................................29
6.5.2 PGP....................................................30
6.5.3 X.509v3................................................30
6.5.4 X9.57..................................................30
6.5.5 SDSI 1.0...............................................30
6.5.6 SPKI...................................................31
6.5.7 SSL....................................................31
6.6 Certificate Result Certificates..........................32
7. Key Management............................................33
7.1 Through Inescapable Names................................33
7.2 Through a Naming Authority...............................33
7.3 Through <name,key> Certificates..........................34
7.4 Increasing Key Lifetimes.................................34
7.5 One Root Per Individual..................................35
7.6 Key Revocation Service...................................36
7.7 Threshold ACL Subjects...................................36
8. Security Considerations...................................37
References...................................................38
Acknowledgments..............................................40
Authors' Addresses...........................................41
Full Copyright Statement.....................................43
This document contains the following sections:
本文件包含以下章节：
Section 2: history of name certification, from 1976 on.
第2节：姓名认证历史，自1976年起。
Section 3: discussion of authorization, rather than authentication, as the desired purpose of a certificate.
第3节：讨论作为证书预期目的的授权，而不是认证。
Section 4: discussion of delegation.
第4节：关于授权的讨论。
Section 5: discussion of validity conditions: date ranges, CRLs, re-validations and one-time on-line validity tests.
第5节：有效性条件讨论：日期范围、CRL、重新验证和一次性在线有效性测试。
Section 6: definition of 5-tuples and their reduction.
第6节：5元组的定义及其约简。
Section 7: discussion of key management.
第7节：关键管理的讨论。
Section 8: security considerations.
第8节：安全考虑。
The References section lists all documents referred to in the text as well as readings which might be of interest to anyone reading on this topic.
参考资料部分列出了文中提到的所有文件，以及任何阅读本主题的人可能感兴趣的阅读资料。
The Acknowledgements section, including a list of contributors primarily from the start of the working group. [The archive of working group mail is a more accurate source of contributor information.]
致谢部分，包括主要从工作组开始的贡献者列表。[工作组邮件存档是投稿人信息的更准确来源。]
The Authors' Addresses section gives the addresses, telephone numbers and e-mail addresses of the authors.
作者地址部分给出了作者的地址、电话号码和电子邮件地址。
We use some terms in the body of this document in ways that could be specific to SPKI:
我们在本文件正文中使用了一些特定于SPKI的术语：
ACL: an Access Control List: a list of entries that anchors a certificate chain. Sometimes called a "list of root keys", the ACL is the source of empowerment for certificates. That is, a certificate communicates power from its issuer to its subject, but the ACL is the source of that power (since it theoretically has the owner of the resource it controls as its implicit issuer). An ACL entry has potentially the same content as a certificate body, but has no Issuer (and is not signed). There is most likely one ACL for each resource owner, if not for each controlled resource.
ACL：访问控制列表：锚定证书链的条目列表。ACL有时被称为“根密钥列表”，它是证书授权的来源。也就是说，证书将权限从其颁发者传递给其主体，但ACL是该权限的来源（因为理论上它将其控制的资源的所有者作为其隐式颁发者）。ACL条目可能具有与证书正文相同的内容，但没有颁发者（且未签名）。如果不是每个受控资源，每个资源所有者很可能有一个ACL。
CERTIFICATE: a signed instrument that empowers the Subject. It contains at least an Issuer and a Subject. It can contain validity conditions, authorization and delegation information. Certificates come in three categories: ID (mapping <name,key>), Attribute (mapping <authorization,name>), and Authorization (mapping <authorization,key>). An SPKI authorization or attribute certificate can pass along all the empowerment it has received from the Issuer or it can pass along only a portion of that empowerment.
证书：授权主体的签字文书。它至少包含一个发行人和一个主题。它可以包含有效性条件、授权和委托信息。证书分为三类：ID（映射<名称，密钥>）、属性（映射<授权，名称>）和授权（映射<授权，密钥>）。SPKI授权或属性证书可以传递其从颁发者处收到的所有授权，也可以只传递该授权的一部分。
ISSUER: the signer of a certificate and the source of empowerment that the certificate is communicating to the Subject.
颁发者：证书的签署者以及证书与主体通信的授权来源。
KEYHOLDER: the person or other entity that owns and controls a given private key. This entity is said to be the keyholder of the keypair or just the public key, but control of the private key is assumed in all cases.
密钥持有人：拥有和控制给定私钥的个人或其他实体。该实体被称为密钥对的密钥持有者或仅为公钥，但在所有情况下都假定对私钥的控制。
PRINCIPAL: a cryptographic key, capable of generating a digital signature. We deal with public-key signatures in this document but any digital signature method should apply.
主体：能够生成数字签名的加密密钥。我们在本文档中处理公钥签名，但应使用任何数字签名方法。
SPEAKING: A Principal is said to "speak" by means of a digital signature. The statement made is the signed object (often a certificate). The Principal is said to "speak for" the Keyholder.
发言：校长通过数字签名“发言”。所做的语句是已签名对象（通常是证书）。据说校长“代表”了钥匙持有者。
SUBJECT: the thing empowered by a certificate or ACL entry. This can be in the form of a key, a name (with the understanding that the name is mapped by certificate to some key or other object), a hash of some object, or a set of keys arranged in a threshold function.
主题：由证书或ACL条目授权的对象。这可以是密钥、名称（理解为名称通过证书映射到某个密钥或其他对象）、某个对象的散列或在阈值函数中排列的一组密钥的形式。
S-EXPRESSION: the data format chosen for SPKI/SDSI. This is a LISP-like parenthesized expression with the limitations that empty lists are not allowed and the first element in any S-expression must be a string, called the "type" of the expression.
S表达式：为SPKI/SDSI选择的数据格式。这是一个类似LISP的带括号的表达式，其限制是不允许使用空列表，并且任何S表达式中的第一个元素必须是字符串，称为表达式的“类型”。
THRESHOLD SUBJECT: a Subject for an ACL entry or certificate that specifies K of N other Subjects. Conceptually, the power being transmitted to the Subject by the ACL entry or certificate is transmitted in (1/K) amount to each listed subordinate Subject. K of those subordinate Subjects must agree (by delegating their shares along to the same object or key) for that power to be passed along. This mechanism introduces fault tolerance and is especially useful in an ACL entry, providing fault tolerance for "root keys".
阈值主题：ACL条目或证书的主题，指定N个其他主题中的K个。从概念上讲，通过ACL条目或证书传输给主体的权力以（1/K）的数量传输给每个列出的下级主体。这些从属主体中的K必须同意（通过将其份额分配给同一对象或密钥）该权力的传递。该机制引入了容错功能，在ACL条目中特别有用，为“根密钥”提供容错功能。
Certificates were originally viewed as having one function: binding names to keys or keys to names. This thought can be traced back to the paper by Diffie and Hellman introducing public key cryptography in 1976. Prior to that time, key management was risky, involved and costly, sometimes employing special couriers with briefcases handcuffed to their wrists.
证书最初被视为具有一个功能：将名称绑定到密钥或将密钥绑定到名称。这种思想可以追溯到Diffie和Hellman在1976年介绍公钥密码术的论文。在此之前，钥匙管理风险高，涉及面广，成本高，有时会雇佣带着手铐的公文包的特别快递员。
Diffie and Hellman thought they had radically solved this problem. "Given a system of this kind, the problem of key distribution is vastly simplified. Each user generates a pair of inverse transformations, E and D, at his terminal. The deciphering transformation, D, must be kept secret but need never be communicated on any channel. The enciphering key, E, can be made public by placing it in a public directory along with the user's name and address. Anyone can then encrypt messages and send them to the user, but no one else can decipher messages intended for him." [DH]
迪菲和赫尔曼认为他们已经从根本上解决了这个问题。“对于此类系统，密钥分配问题大大简化。每个用户在其终端生成一对逆变换E和D。解密转换D必须保密，但不需要在任何通道上进行通信。加密密钥E可以通过将其放在公共目录alo中公开任何人都可以加密信息并将其发送给用户，但其他人无法破译为他发送的信息。”[DH]
This modified telephone book, fully public, took the place of the trusted courier. This directory could be put on-line and therefore be available on demand, worldwide. In considering that prospect, Loren Kohnfelder, in his 1978 bachelor's thesis in electrical engineering from MIT [KOHNFELDER], noted: "Public-key communication works best when the encryption functions can reliably be shared among
这本经过修改的电话簿完全公开，取代了受信任的信使。该目录可在线发布，因此可在全球范围内按需提供。考虑到这一前景，Loren Kohnfeld在其1978年麻省理工学院（MIT）电气工程学士学位论文[Kohnfeld]中指出：“当加密功能可以可靠地共享时，公钥通信效果最佳
the communicants (by direct contact if possible). Yet when such a reliable exchange of functions is impossible the next best thing is to trust a third party. Diffie and Hellman introduce a central authority known as the Public File."
通信方（如有可能，通过直接接触）。然而，当这种可靠的功能交换不可能时，下一个最好的办法是信任第三方。Diffie和Hellman引入了一个称为公共文件的中央机构。”
Kohnfelder then noted, "Each individual has a name in the system by which he is referenced in the Public File. Once two communicants have gotten each other's keys from the Public File they can securely communicate. The Public File digitally signs all of its transmissions so that enemy impersonation of the Public File is precluded." In an effort to prevent performance problems, Kohnfelder invented a new construct: a digitally signed data record containing a name and a public key. He called this new construct a CERTIFICATE. Because it was digitally signed, such a certificate could be held by non-trusted parties and passed around from person to person, resolving the performance problems involved in a central directory.
科恩费尔德接着指出，“每个人在系统中都有一个名字，他在公共文件中被引用。一旦两个通信者从公共文件中获得了彼此的密钥，他们就可以安全地通信。公共文件对其所有传输进行数字签名，以防止敌人模仿公共文件。”为了防止性能问题，Kohnfeld发明了一种新的结构：一种包含名称和公钥的数字签名数据记录。他把这种新构造称为证书。因为它是数字签名的，这样的证书可以由不受信任的方持有，并在人与人之间传递，从而解决了中央目录中涉及的性能问题。
Ten years after Kohnfelder's thesis, the ISO X.509 recommendation was published as part of X.500. X.500 was to be a global, distributed database of named entities: people, computers, printers, etc. In other words, it was to be a global, on-line telephone book. The organizations owning some portion of the name space would maintain that portion and possibly even provide the computers on which it was stored. X.509 certificates were defined to bind public keys to X.500 path names (Distinguished Names) with the intention of noting which keyholder had permission to modify which X.500 directory nodes. In fact, the X.509 data record was originally designed to hold a password instead of a public key as the record-access authentication mechanism.
Kohnfeld的论文发表十年后，ISO X.509建议作为X.500的一部分发布。X.500将是一个全球性的、分布式的命名实体数据库：人、计算机、打印机等。换句话说，它将是一个全球性的在线电话簿。拥有部分名称空间的组织将维护该部分，甚至可能提供存储名称空间的计算机。定义X.509证书以将公钥绑定到X.500路径名（可分辨名称），目的是说明哪个密钥持有者有权修改哪个X.500目录节点。事实上，X.509数据记录最初设计用于保存密码，而不是作为记录访问身份验证机制的公钥。
The original X.500 plan is unlikely ever to come to fruition. Collections of directory entries (such as employee lists, customer lists, contact lists, etc.) are considered valuable or even confidential by those owning the lists and are not likely to be released to the world in the form of an X.500 directory sub-tree. For an extreme example, imagine the CIA adding its directory of agents to a world-wide X.500 pool.
最初的X.500计划不太可能实现。目录条目的集合（如员工列表、客户列表、联系人列表等）被拥有这些列表的人认为是有价值的，甚至是机密的，不可能以X.500目录子树的形式发布到世界各地。举一个极端的例子，想象一下CIA将其代理目录添加到一个世界范围的X.500池中。
The X.500 idea of a distinguished name (a single, globally unique name that everyone could use when referring to an entity) is also not likely to occur. That idea requires a single, global naming discipline and there are too many entities already in the business of defining names not under a single discipline. Legacy therefore militates against such an idea.
X.500关于可分辨名称（每个人在提及实体时都可以使用的单一、全球唯一的名称）的想法也不太可能出现。这种想法需要一个单一的、全局的命名规则，而且已经有太多的实体在定义不属于单一规则的名称。因此，遗产不利于这种想法。
The Privacy Enhanced Mail [PEM] effort of the Internet Engineering Task Force [RFC1114] adopted X.509 certificates, but with a different interpretation. Where X.509 was originally intended to mean "the keyholder may modify this portion of the X.500 database", PEM took the certificate to mean "the key speaks for the named person". What had been an access control instrument was now an identity instrument, along the lines envisioned by Diffie, Hellman and Kohnfelder.
互联网工程任务组[RFC1114]的隐私增强邮件[PEM]工作采用了X.509证书，但有不同的解释。如果X.509最初的意思是“钥匙持有人可以修改X.500数据库的这一部分”，PEM认为证书的意思是“钥匙代表指定的人”。按照迪菲、赫尔曼和科恩费尔德的设想，曾经的访问控制工具现在变成了身份识别工具。
The insistence on X.509 certificates with a single global root delayed PEM's adoption past its window of viability. RIPEM, by Mark Riordan of MSU, was a version of PEM without X.509 certificates. It was distributed and used by a small community, but fell into disuse. MOSS (a MIME-enhanced version of PEM, produced by TIS (www.tis.com)) made certificate use optional, but received little distribution.
坚持使用具有单个全局根的X.509证书推迟了PEM的采用，使其超过了生存期。由密歇根州立大学的马克·里奥丹（MarkRiordan）设计的RIPEM是一个没有X.509证书的PEM版本。它被一个小社区分发和使用，但被废弃了。MOSS（由TIS（www.TIS.com）制作的PEM的MIME增强版）使证书的使用成为可选的，但很少得到分发。
At about the same time, in 1991, Phil Zimmermann's PGP was introduced with a different certificate model. Instead of waiting for a single global root and the hierarchy of Certificate Authorities descending from that root, PGP allowed multiple, (hopefully) independent but not specially trusted individuals to sign a <name,key> association, attesting to its validity. The theory was that with enough such signatures, that association could be trusted because not all of these signer would be corrupt. This was known as the "web of trust" model. It differed from X.509 in the method of assuring trust in the <name,key> binding, but it still intended to bind a globally unique name to a key. With PEM and PGP, the intention was for a keyholder to be known to anyone in the world by this certified global name.
大约在同一时间，在1991年，Phil Zimmermann的PGP引入了一种不同的证书模型。PGP不需要等待单个全局根和从该根开始的证书颁发机构层次结构，而是允许多个（希望是）独立但不受特别信任的个人签署<name，key>关联，以证明其有效性。该理论认为，有了足够多的此类签名，这种关联可以被信任，因为并非所有这些签名者都会腐败。这被称为“信任网”模型。它与X.509的不同之处在于确保<name，key>绑定中的信任的方法，但它仍然打算将全局唯一的名称绑定到密钥。有了PEM和PGP，其目的是让世界上任何人都能通过这个认证的全球名称认识钥匙持有人。
The assumption that the job of a certificate was to bind a name to a key made sense when it was first published. In the 1970's, people operated in relatively small communities. Relationships formed face to face. Once you knew who someone was, you often knew enough to decide how to behave with that person. As a result, people have reduced this requirement to the simply stated: "know who you're dealing with".
证书的任务是将名称绑定到密钥的假设在首次发布时是有意义的。在20世纪70年代，人们在相对较小的社区开展活动。面对面的关系。一旦你知道一个人是谁，你通常就知道如何与他相处。因此，人们将这一要求简化为“知道你在和谁打交道”。
Names, in turn, are what we humans use as identifiers of persons. We learn this practice as infants. In the family environment names work as identifiers, even today. What we learn as infants is especially difficult to re-learn later in life. Therefore, it is natural for people to translate the need to know who the keyholder is into a need to know the keyholder's name.
名字，反过来，是我们人类用来作为人的标识符的东西。我们在婴儿时期就学会了这种做法。即使在今天，在家族环境中，名字也是标识符。我们在婴儿时期所学的东西在以后的生活中尤其难以重新学习。因此，人们自然会将了解持钥匙人的需求转化为了解持钥匙人姓名的需求。
Computer applications need to make decisions about keyholders. These decisions are almost never made strictly on the basis of a keyholder's name. There is some other fact about the keyholder of interest to the application (or to the human being running the application). If a name functions at all for security purposes, it is as an index into some database (or human memory) of that other information. To serve in this role, the name must be unique, in order to serve as an index, and there must be some information to be indexed.
计算机应用程序需要对键盘持有者做出决定。这些决定几乎从来没有严格根据钥匙持有人的姓名做出。关于应用程序（或运行应用程序的人）感兴趣的密钥持有者还有其他一些事实。如果一个名称是出于安全目的而起作用的，那么它将作为其他信息的某个数据库（或人类内存）的索引。要担任此角色，名称必须是唯一的，才能用作索引，并且必须有一些信息要编制索引。
The names we use to identify people are usually unique, within our local domain, but that is not true on a global scale. It is extremely unlikely that the name by which we know someone, a given name, would function as a unique identifier on the Internet. Given names continue to serve the social function of making the named person feel recognized when addressed by name but they are inadequate as the identifiers envisioned by Diffie, Hellman and Kohnfelder.
在我们的本地域中，我们用来识别人的名字通常是唯一的，但在全球范围内并非如此。我们认识某人的名字，一个给定的名字，在互联网上作为唯一的标识符是极不可能的。命名继续发挥着社会功能，使被命名的人在被命名时感到被认可，但它们不足以作为Diffie、Hellman和Kohnfeld所设想的标识符。
In the 1970's and even through the early 1990's, relationships formed in person and one could assume having met the keyholder and therefore having acquired knowledge about that person. If a name could be found that was an adequate identifier of that keyholder, then one might use that name to index into memories about the keyholder and then be able to make the relevant decision.
在20世纪70年代，甚至整个90年代初，人际关系都是亲自形成的，人们可以假设已经见过钥匙持有人，因此已经了解了此人。如果可以找到一个名字，这个名字是该钥匙持有者的适当标识符，那么人们可以使用这个名字索引到关于钥匙持有者的记忆中，然后能够做出相关的决定。
In the late 1990's, this is no longer true. With the explosion of the Internet, it is likely that one will encounter keyholders who are complete strangers in the physical world and will remain so. Contact will be made digitally and will remain digital for the duration of the relationship. Therefore, on first encounter there is no body of knowledge to be indexed by any identifier.
在20世纪90年代末，这已不再是事实。随着互联网的爆炸式发展，人们很可能会遇到在现实世界中完全陌生的钥匙持有者，并且他们将一直如此。联系将以数字方式进行，并在关系存续期间保持数字联系。因此，在第一次接触时，没有任何标识符可以对知识体进行索引。
One might consider building a global database of facts about all persons in the world and making that database available (perhaps for a fee). The name that indexes that database might also serve as a globally unique ID for the person referenced. The database entry under that name could contain all the information needed to allow someone to make a security decision. Since there are multiple decision-makers, each interested in specific information, the database would need to contain the union of multiple sets of information. However, that solution would constitute a massive privacy violation and would probably be rejected as politically impossible.
人们可能会考虑建立一个关于世界上所有人的事实数据库并使其成为可用的数据库（也许是收费）。为该数据库编制索引的名称也可以用作所引用人员的全局唯一ID。该名称下的数据库条目可以包含允许某人做出安全决策所需的所有信息。由于有多个决策者，每个决策者都对特定信息感兴趣，因此数据库需要包含多组信息的联合。然而，这一解决方案将构成对隐私的大规模侵犯，并可能因政治上不可能而遭到拒绝。
A globally unique ID might even fail when dealing with people we do know. Few of us know the full given names of people with whom we deal. A globally unique name for a person would be larger than the full given name (and probably contain it, out of deference to a
与我们认识的人打交道时，全球唯一的ID甚至可能失败。我们中很少有人知道与我们打交道的人的全名。一个人的全局唯一名称将大于完整的给定名称（并且可能包含该名称，出于对特定名称的尊重）
person's fondness for his or her own name). It would therefore not be a name by which we know the person, barring a radical change in human behavior.
个人对自己名字的喜爱）。因此，除非人类行为发生根本性变化，否则它将不是我们认识这个人的名字。
A globally unique ID that contains a person's given name poses a special danger. If a human being is part of the process (e.g., scanning a database of global IDs in order to find the ID of a specific person for the purpose of issuing an attribute certificate), then it is likely that the human operator would pay attention to the familiar portion of the ID (the common name) and pay less attention to the rest. Since the common name is not an adequate ID, this can lead to mistakes. Where there can be mistakes, there is an avenue for attack.
包含人名的全局唯一ID会带来特殊的危险。如果人员是该过程的一部分（例如，扫描全局ID数据库以查找特定人员的ID以颁发属性证书），则人员操作员可能会关注ID的熟悉部分（通用名称），而较少关注其余部分。由于通用名称不是一个适当的ID，因此可能会导致错误。哪里有错误，哪里就有攻击的途径。
Where globally unique identifiers need to be used, perhaps the best ID is one that is uniform in appearance (such as a long number or random looking text string) so that it has no recognizable sub-field. It should also be large enough (from a sparse enough name space) that typographical errors would not yield another valid identifier.
在需要使用全局唯一标识符的情况下，最好的ID可能是外观统一的ID（例如长数字或随机外观的文本字符串），因此它没有可识别的子字段。它还应该足够大（从一个足够稀疏的名称空间），以使印刷错误不会产生另一个有效的标识符。
Some people speak of global IDs as if they were inescapable identifiers, able to prevent someone from doing evil under one name, changing his name and starting over again. To make that scenario come true, one would have to have assignment of such identifiers (probably by governments, at birth) and some mechanism so that it is always possible to get from any flesh and blood person back to his or her identifier. Given that latter mechanism, any Certificate Authority desiring to issue a certificate to a given individual would presumably choose the same, inescapable name for that certificate. A full set of biometrics might suffice, for example, to look up a person without danger of false positive in a database of globally assigned ID numbers and with that procedure one could implement inescapable IDs.
有些人将全局ID视为无法逃避的标识符，能够阻止某人用一个名字做坏事，更改他的名字并重新开始。要实现这一设想，就必须有这样的身份识别码（可能是政府在出生时指定的）和某种机制，以便始终能够从任何有血有肉的人那里获得他或她的身份识别码。鉴于后一种机制，任何希望向给定个人颁发证书的证书颁发机构都可能会为该证书选择相同的、不可避免的名称。例如，一整套生物识别技术可能足以在全球分配的身份证号码数据库中查找一个人，而不会有误报的危险，通过这一程序，可以实现不可避免的身份证。
The use of an inescapable identifier might be possible in some countries, but in others (such as the US) it would meet strong political opposition. Some countries have government-assigned ID numbers for citizens but also have privacy regulations that prohibit the use of those numbers for routine business. In either of these latter cases, the inescapable ID would not be available for use in routine certificates.
在某些国家使用不可避免的标识符可能是可能的，但在其他国家（如美国），这将遭到强烈的政治反对。一些国家有政府为公民分配的身份证号码，但也有隐私条例，禁止在日常事务中使用这些号码。在后两种情况中的任何一种情况下，不可避免的ID都不能用于常规证书。
There was a concern that commercial Certificate Authorities might have been used to bring inescapable names into existence, bypassing the political process and the opposition to such names in those countries where such opposition is strong. As the (name,key)
有人担心，商业证书管理机构可能被用来建立无法逃避的名称，绕过政治进程，并在反对声音强烈的国家反对这些名称。作为（名称、键）
certificate business is evolving today, there are multiple competing CAs each creating disjoint Distinguished Name spaces. There is also no real block to the creation of new CAs. Therefore a person is able to drop one Distinguished Name and get another, by changing CA, making these names not inescapable.
证书业务在不断发展，有多个相互竞争的CA，每个CA都创建不相交的专有名称空间。创建新CA也没有真正的障碍。因此，通过改变CA，一个人可以去掉一个可分辨的名字而得到另一个，使这些名字不是不可避免的。
Globally unique names may be politically undesirable and relatively useless, in the world of the Internet, but we use names all the time.
在互联网世界中，全球唯一的名字可能在政治上不受欢迎，而且相对来说毫无用处，但我们一直在使用名字。
The names we use are local names. These are the names we write in our personal address books or use as nicknames or aliases with e-mail agents. They can be IDs assigned by corporations (e.g., bank account numbers or employee numbers). Those names or IDs do not need to be globally unique. Rather, they need to be unique for the one entity that maintains that address book, e-mail alias file or list of accounts. More importantly, they need to be meaningful to the person who uses them as indexes.
我们使用的名称是本地名称。这些是我们在个人通讯簿中写下的姓名，或作为电子邮件代理的昵称或别名。它们可以是公司分配的ID（例如，银行账号或员工编号）。这些名称或ID不需要全局唯一。相反，对于维护地址簿、电子邮件别名文件或帐户列表的实体，它们需要是唯一的。更重要的是，它们需要对使用它们作为索引的人有意义。
Ron Rivest and Butler Lampson showed with SDSI 1.0 [SDSI] that one can not only use local names locally, one can use local names globally. The clear security advantage and operational simplicity of SDSI names caused us in the SPKI group to adopt SDSI names as part of the SPKI standard.
Ron Rivest和Butler Lampson通过SDSI 1.0[SDSI]表明，人们不仅可以在本地使用本地名称，还可以在全球范围内使用本地名称。SDSI名称的明显安全优势和操作简单性促使我们SPKI集团采用SDSI名称作为SPKI标准的一部分。
A basic SDSI 2.0 name is an S-expression with two elements: the word "name" and the chosen name. For example,
基本SDSI 2.0名称是一个S表达式，包含两个元素：单词“name”和所选名称。例如
george: (name fred)
乔治：（叫弗雷德）
represents a basic SDSI name "fred" in the name space defined by george.
表示george定义的名称空间中的基本SDSI名称“fred”。
If fred in turn defines a name, for example,
例如，如果fred反过来定义了一个名称，
fred: (name sam)
弗雷德：（叫山姆）
then george can refer to this same entity as
那么george可以将这个实体称为
george: (name fred sam)
乔治：（名字叫弗雷德·萨姆）
Even though humans use local names, computer systems often need globally unique identifiers. Even in the examples of section 2.6.2 above, we needed to make the local names more global and did so by specifying the name-space owner.
即使人类使用本地名称，计算机系统通常也需要全局唯一的标识符。即使在上面第2.6.2节的示例中，我们也需要通过指定名称空间所有者使本地名称更具全局性。
If we are using public key cryptography, we have a ready source of globally unique identifiers.
如果我们使用的是公钥密码，那么我们就有了一个全局唯一标识符的现成来源。
When one creates a key pair, for use in public key cryptography, the private key is bound to its owner by good key safeguarding practice. If that private key gets loose from its owner, then a basic premise of public key cryptography has been violated and that key is no longer of interest.
当创建一对密钥用于公钥加密时，私钥通过良好的密钥保护实践绑定到其所有者。如果私钥从其所有者处丢失，则公钥加密的基本前提已被违反，并且该密钥不再受关注。
The private key is also globally unique. If it were not, then the key generation process would be seriously flawed and we would have to abandon this public key system implementation.
私钥也是全局唯一的。如果不是，那么密钥生成过程将有严重缺陷，我们将不得不放弃这种公钥系统实现。
The private key must be kept secret, so it is not a possible identifier, but each public key corresponds to one private key and therefore to one keyholder. The public key, viewed as a byte string, is therefore an identifier for the keyholder.
私钥必须保密，因此它不是可能的标识符，但每个公钥对应一个私钥，因此对应一个密钥持有者。因此，公钥被视为字节字符串，是密钥持有者的标识符。
If there exists a collision-free hash function, then a collision-free hash of the public key is also a globally unique identifier for the keyholder, and probably a shorter one than the public key.
如果存在无冲突散列函数，则公钥的无冲突散列也是密钥持有者的全局唯一标识符，并且可能比公钥短。
SDSI local names are of great value to their definer. Each local name maps to one or more public keys and therefore to the corresponding keyholder(s). Through SDSI's name chaining, these local names become useful potentially to the whole world. [See section 2.6.2 for an example of SDSI name chaining.]
SDSI本地名称对其定义者来说非常有价值。每个本地名称映射到一个或多个公钥，因此映射到相应的密钥持有者。通过SDSI的名称链，这些本地名称可能对整个世界有用。[有关SDSI名称链接的示例，请参见第2.6.2节。]
To a computer system making use of these names, the name string is not enough. One must identify the name space in which that byte string is defined. That name space can be identified globally by a public key.
对于使用这些名称的计算机系统，名称字符串是不够的。必须标识定义该字节字符串的名称空间。该名称空间可以通过公钥进行全局标识。
It is SDSI 1.0 convention, preserved in SPKI, that if a (local) SDSI name occurs within a certificate, then the public key of the issuer is the identifier of the name space in which that name is defined.
SPKI中保留的SDSI 1.0约定是，如果（本地）SDSI名称出现在证书中，则颁发者的公钥是定义该名称的名称空间的标识符。
However, if a SDSI name is ever to occur outside of a certificate, the name space within which it is defined must be identified. This gives rise to the Fully Qualified SDSI Name. That name is a public key followed by one or more names relative to that key. If there are two or more names, then the string of names is a SDSI name chain. For example,
但是，如果SDSI名称出现在证书之外，则必须标识定义该名称的名称空间。这就产生了完全限定的SDSI名称。该名称是一个公钥，后跟一个或多个与该密钥相关的名称。如果有两个或多个名称，则名称字符串是SDSI名称链。例如
(name (hash sha1 |TLCgPLFlGTzgUbcaYLW8kGTEnUk=|) jim therese)
（姓名（hash sha1 | tlcgpllflgtzgubcaylw8kgtenuk=|）jim therese）
is a fully qualified SDSI name, using the SHA-1 hash of a public key as the global identifier defining the name space and anchoring this name string.
是一个完全限定的SDSI名称，使用公钥的SHA-1哈希作为定义名称空间并锚定此名称字符串的全局标识符。
An X.509 Distinguished Name can and sometimes must be expressed as a Fully Qualified Name. If the PEM or original X.500 vision of a single root for a global name space had come true, this wouldn't be necessary because all names would be relative to that same one root key. However, there is not now and is not likely ever to be a single root key. Therefore, every X.509 name should be expressed as the pair
X.509可分辨名称可以而且有时必须表示为完全限定名称。如果PEM或最初的X.500对全局名称空间使用单个根的设想已经实现，那么就没有必要这样做，因为所有名称都将与同一个根键相关。但是，现在没有，也不可能永远没有一个根键。因此，每个X.509名称都应表示为对
(name <root key> <leaf name>)
(name <root key> <leaf name>)
if all leaf names descending from that root are unique. If uniqueness is enforced only within each individual CA, then one would build a Fully Qualified Name chain from an X.509 certificate chain, yielding the form
如果从该根开始的所有叶名称都是唯一的。如果唯一性仅在每个CA中强制执行，则可以从X.509证书链构建一个完全限定的名称链，从而生成
(name <root key> <CA(1)> <CA(2)> ... <CA(k)> <leaf name>).
（名称<root key><CA（1）><CA（2）>…<CA（k）><leaf name>）。
SPKI/SDSI does not claim to enforce one key per name. Therefore, a named group can be defined by issuing multiple (name,key) certificates with the same name -- one for each group member.
SPKI/SDSI不要求每个名称强制执行一个密钥。因此，可以通过颁发多个同名（名称、密钥）证书来定义命名组——每个组成员一个证书。
Fully qualified SDSI names represent globally unique names, but at every step of their construction the local name used is presumably meaningful to the issuer. Therefore, with SDSI name certificates one can identify the keyholder by a name relevant to someone.
完全限定的SDSI名称表示全局唯一的名称，但在其构造的每个步骤中，所使用的本地名称可能对发行人都有意义。因此，使用SDSI名称证书，可以通过与某人相关的名称来识别密钥持有者。
However, what an application needs to do, when given a public key certificate or a set of them, is answer the question of whether the remote keyholder is permitted some access. That application must make a decision. The data needed for that decision is almost never the spelling of a keyholder's name.
然而，当一个应用程序获得一个公钥证书或一组公钥证书时，它需要做的是回答远程密钥持有者是否被允许访问的问题。该应用程序必须做出决定。做出这一决定所需的数据几乎从来都不是钥匙持有者姓名的拼写。
Instead, the application needs to know if the keyholder is authorized for some access. This is the primary job of a certificate, according to the members of the SPKI WG, and the SPKI certificate was designed to meet this need as simply and directly as possible.
相反，应用程序需要知道钥匙持有者是否被授权进行某些访问。据SPKI工作组成员介绍，这是证书的主要工作，SPKI证书旨在尽可能简单直接地满足这一需求。
We realize that the world is not going to switch to SPKI certificates overnight. Therefore, we developed an authorization computation process that can use certificates in any format. That process is described below in section 6.
我们意识到，世界不会在一夜之间转向SPKI证书。因此，我们开发了一个授权计算过程，可以使用任何格式的证书。下文第6节介绍了该过程。
The various methods of establishing authorization are documented below, briefly. (See also [UPKI])
下文简要介绍了建立授权的各种方法。（另见[UPKI]）
An Attribute Certificate, as defined in X9.57, binds an attribute that could be an authorization to a Distinguished Name. For an application to use this information, it must combine an attribute certificate with an ID certificate, in order to get the full mapping:
X9.57中定义的属性证书将可能是授权的属性绑定到可分辨名称。对于要使用此信息的应用程序，它必须将属性证书与ID证书相结合，才能获得完整的映射：
authorization -> name -> key
authorization -> name -> key
Presumably the two certificates involved came from different issuers, one an authority on the authorization and the other an authority on names. However, if either of these issuers were subverted, then an attacker could obtain an authorization improperly. Therefore, both the issuers need to be trusted with the authorization decision.
可能涉及的两个证书来自不同的发行人，一个是授权机构，另一个是名称机构。但是，如果这些发行者中的任何一个被颠覆，则攻击者可能会不正确地获得授权。因此，两个发行人都需要信任授权决策。
X.509v3 permits general extensions. These extensions can be used to carry authorization information. This makes the certificate an instrument mapping both:
X.509v3允许一般扩展。这些扩展可以用来携带授权信息。这使证书成为一种仪器映射，包括：
authorization -> key
授权->密钥
and
和
name -> key
名称->键
In this case, there is only one issuer, who must be an authority on both the authorization and the name.
在这种情况下，只有一个发行人，必须是授权和名称的权威。
Some propose issuing a master X.509v3 certificate to an individual and letting extensions hold all the attributes or authorizations the individual would need. This would require the issuer to be an authority on all of those authorizations. In addition, this aggregation of attributes would result in shortening the lifetime of the certificate, since each attribute would have its own lifetime. Finally, aggregation of attributes amounts to the building of a dossier and represents a potential privacy violation.
一些人建议向个人颁发master X.509v3证书，并允许扩展保存个人需要的所有属性或授权。这将要求发行人成为所有这些授权的权威。此外，由于每个属性都有自己的生存期，因此这种属性聚合将缩短证书的生存期。最后，属性的聚合相当于建立档案，并表示潜在的隐私侵犯。
For all of these reasons, it is desirable that authorizations be limited to one per certificate.
出于所有这些原因，最好将授权限制为每个证书一个。
A basic SPKI certificate defines a straight authorization mapping:
基本SPKI证书定义了直接授权映射：
authorization -> key
授权->密钥
If someone wants access to a keyholder's name, for logging purposes or even for punishment after wrong-doing, then one can map from key to location information (name, address, phone, ...) to get:
如果有人想要访问钥匙持有人的姓名，出于记录目的，甚至是为了惩罚错误行为，那么可以将钥匙映射到位置信息（姓名、地址、电话等）以获得：
authorization -> key -> name
authorization -> key -> name
This mapping has an apparent security advantage over the attribute certificate mapping. In the mapping above, only the
与属性证书映射相比，此映射具有明显的安全优势。在上面的映射中，只有
authorization -> key
授权->密钥
mapping needs to be secure at the level required for the access control mechanism. The
映射需要在访问控制机制所需的级别上保持安全。这个
key -> name
键->名称
mapping (and the issuer of any certificates involved) needs to be secure enough to satisfy lawyers or private investigators, but a subversion of this mapping does not permit the attacker to defeat the access control. Presumably, therefore, the care with which these certificates (or database entries) are created is less critical than the care with which the authorization certificate is issued. It is also possible that the mapping to name need not be on-line or protected as certificates, since it would be used by human investigators only in unusual circumstances.
映射（以及涉及的任何证书的颁发者）需要足够安全，以满足律师或私人调查人员的要求，但对该映射的颠覆不允许攻击者破坏访问控制。因此，据推测，创建这些证书（或数据库条目）的谨慎程度低于颁发授权证书的谨慎程度。也有可能，到名称的映射不需要在线或作为证书进行保护，因为只有在异常情况下，人类调查人员才会使用它。
SDSI 1.0 defined an ACL, granting authorization to names. It was then like an attribute certificate, except that it did not need to be signed or issued by any key. It was held in local memory and was assumed issued by the owner of the computer and therefore of the resource being controlled.
SDSI 1.0定义了一个ACL，向名称授予授权。它当时就像一个属性证书，只是它不需要由任何密钥签名或颁发。它被保存在本地内存中，并假定是由计算机的所有者发布的，因此是被控制的资源的所有者。
In SPKI, an ACL entry is free to be implemented in any way the developer chooses, since it is never communicated and therefore does not need to be standardized. However, a sample implementation is documented, as a certificate body minus the issuer field. The ACL entry can have a name as a subject, as in SDSI 1.0, or it can have a key as a subject. Examples of the latter include the list of SSL root keys in an SSL capable browser or the file .ssh/authorized_keys in a user's home UNIX directory. Those ACLs are single-purpose, so the individual entries do not carry explicit authorizations, but SPKI uses explicit authorizations so that one can use common authorization computation code to deal with multiple applications.
在SPKI中，ACL条目可以自由地以开发人员选择的任何方式实现，因为它从不进行通信，因此不需要标准化。但是，将记录一个示例实现，作为证书主体减去颁发者字段。ACL条目可以有一个名称作为主题，如SDSI 1.0中所述，也可以有一个键作为主题。后者的示例包括支持SSL的浏览器中的SSL根密钥列表或用户主UNIX目录中的.ssh/authorized_密钥文件。这些ACL是单一用途的，因此单个条目不携带显式授权，但SPKI使用显式授权，因此可以使用通用授权计算代码来处理多个应用程序。
One of the powers of an authorization certificate is the ability to delegate authorizations from one person to another without bothering the owner of the resource(s) involved. One might issue a simple permission (e.g., to read some file) or issue the permission to delegate that permission further.
授权证书的一项权力是能够将授权从一个人委托给另一个人，而不会打扰相关资源的所有者。可以颁发简单权限（例如，读取某个文件）或颁发进一步委托该权限的权限。
Two issues arose as we considered delegation: the desire to limit depth of delegation and the question of separating delegators from those who can exercise the delegated permission.
在我们考虑授权时，出现了两个问题：限制授权深度的愿望和将授权人与能够行使授权权限的人分开的问题。
There were three camps in discussing depth of delegation: no control, boolean control and integer control. There remain camps in favor of each of these, but a decision was reached in favor of boolean control.
在讨论委托深度时有三个阵营：无控制、布尔控制和整数控制。目前仍有支持每种方法的阵营，但达成了支持布尔控制的决定。
The argument in favor of no control is that if a keyholder is given permission to do something but not the permission to delegate it, then it is possible for that keyholder to loan out the empowered private key or to set up a proxy service, signing challenges or requests for the intended delegate. Therefore, the attempt to restrict the permission to delegate is ineffective and might back-fire, by leading to improper security practices.
支持无控制的理由是，如果某个密钥持有人被授予做某件事的权限，但没有授予授权的权限，那么该密钥持有人就有可能借出授权的私钥或建立代理服务，为指定的授权人签署质疑或请求。因此，限制委派权限的尝试是无效的，并且可能会导致不正确的安全做法，从而引发回击。
The argument in favor of boolean control is that one might need to specify an inability to delegate. For example, one could imagine the US Commerce Department having a key that is authorized to declare a cryptographic software module exportable and also to delegate that authorization to others (e.g., manufacturers). It is reasonable to assume the Commerce Department would not issue permission to delegate this further. That is, it would want to have a direct legal agreement with each manufacturer and issue a certificate to that manufacturer only to reflect that the legal agreement is in place.
支持布尔控制的理由是，可能需要指定无法委托。例如，可以想象美国商务部拥有一个密钥，该密钥被授权声明加密软件模块可出口，并将该授权委托给其他人（如制造商）。我们有理由假设商务部不会批准进一步授权。也就是说，它希望与每个制造商签订直接法律协议，并向该制造商颁发证书，以反映法律协议已到位。
The argument in favor of integer control is that one might want to restrict the depth of delegation in order to control the proliferation of a delegated permission.
支持整数控制的理由是，可能需要限制委托的深度，以控制委托权限的扩散。
Of these three, the group chose boolean control. The subject of a certificate or ACL entry may exercise any permission granted and, if delegation is TRUE, may also delegate that permission or some subset of it to others.
在这三个选项中，小组选择了布尔控制。证书或ACL条目的主体可以行使授予的任何权限，如果委托为真，还可以将该权限或其某个子集委托给其他人。
The no control argument has logical appeal, but there remains the assumption that a user will value his or her private key enough not to loan it out or that the key will be locked in hardware where it can't be copied to any other user. This doesn't prevent the user from setting up a signing oracle, but lack of network connectivity might inhibit that mechanism.
“无控制”参数在逻辑上具有吸引力，但仍然存在这样的假设：用户将对其私钥进行足够的估价，从而不会将其借出，或者该密钥将被锁定在硬件中，无法复制给任何其他用户。这不会阻止用户设置oracle签名，但缺少网络连接可能会抑制该机制。
The integer control option was the original design and has appeal, but was defeated by the inability to predict the proper depth of delegation. One can always need to go one more level down, by creating a temporary signing key (e.g., for use in a laptop). Therefore, the initially predicted depth could be significantly off.
整数控制选项是最初的设计，具有吸引力，但由于无法预测适当的委托深度而失败。通过创建临时签名密钥（例如，在笔记本电脑中使用），您可能需要再向下一级。因此，最初预测的深度可能会显著偏离。
As for controlling the proliferation of permissions, there is no control on the width of the delegation tree, so control on its depth is not a tight control on proliferation.
至于控制权限的扩散，没有对委托树的宽度进行控制，因此对其深度的控制不是对扩散的严格控制。
We decided that a delegator is free to create a new key pair, also controlled by it, and delegate the rights to that key to exercise the delegated permission. Therefore, there was no benefit from attempting to restrict the exercise of a permission by someone permitted to delegate it.
我们决定委托人可以自由创建一个新的密钥对（也由其控制），并将该密钥的权限委托给该密钥以行使委托权限。因此，试图限制被允许授权的人行使许可没有任何好处。
One concern with defining an authorization certificate is that the function can be performed by traditional <authorization,name> ACLs and <name,key> ID certificates defining groups. Such a mechanism was described in SDSI 1.0. A new mechanism needs to add value or it just complicates life for the developer.
定义授权证书的一个问题是，该功能可以由传统的<authorization，name>acl和<name，key>ID证书定义组执行。SDSI 1.0中描述了这种机制。一种新的机制需要增加价值，否则只会使开发人员的生活复杂化。
The argument for delegated authorization as opposed to ACLs can be seen in the following example.
与ACL相反，委托授权的参数可以在下面的示例中看到。
Imagine a firewall proxy permitting telnet and ftp access from the Internet into a network of US DoD machines. Because of the sensitivity of that destination network, strong access control would be desired. One could use public key authentication and public key certificates to establish who the individual keyholder was. Both the private key and the keyholder's certificates could be kept on a Fortezza card. That card holds X.509v1 certificates, so all that can be established is the name of the keyholder. It is then the job of the firewall to keep an ACL, listing named keyholders and the forms of access they are each permitted.
想象一下，一个防火墙代理允许telnet和ftp从互联网访问美国国防部机器网络。由于目的地网络的敏感性，需要强大的访问控制。可以使用公钥身份验证和公钥证书来确定个人密钥持有者是谁。私钥和密钥持有者的证书都可以保存在Fortezza卡上。该卡持有X.509v1证书，因此只能确定密钥持有者的名称。然后，防火墙的工作就是保存一个ACL，列出指定的密钥持有者及其各自允许的访问形式。
Consider the ACL itself. Not only would it be potentially huge, demanding far more storage than the firewall would otherwise require, but it would also need its own ACL. One could not, for example, have someone in the Army have the power to decide whether someone in the Navy got access. In fact, the ACL would probably need not one level of its own ACL, but a nested set of ACLs, eventually reflecting the organization structure of the entire Defense Department.
考虑ACL本身。它不仅可能非常庞大，需要的存储空间远远超过防火墙的要求，而且还需要自己的ACL。例如，不能让陆军中的某个人有权决定海军中的某个人是否可以访问。事实上，ACL可能不需要自己的一级ACL，而是一组嵌套的ACL，最终反映整个国防部的组织结构。
Without the ACLs, the firewall could be implemented in a device with no mass storage, residing in a sealed unit one could easily hold in one hand. With the ACLs, it would need a large mass storage device that would be accessed not only while making access control decisions but also for updating the ACLs.
如果没有ACL，防火墙可以在没有大容量存储的设备中实现，驻留在一只手可以轻松握住的密封单元中。对于ACL，它需要一个大容量存储设备，不仅在做出访问控制决策时可以访问该设备，而且还可以更新ACL。
By contrast, let the access be controlled by authorization certificates. The firewall would have an ACL with one entry, granting a key belonging to the Secretary of Defense the right to delegate all access through the firewall. The Secretary would, in
相反，让访问由授权证书控制。防火墙将有一个带有一个入口的ACL，授予国防部长的密钥通过防火墙授权所有访问的权利。局长会在
turn, issue certificates delegating this permission to delegate to each of his or her subordinates. This process would iterate, until some enlisted man would receive permission to penetrate that firewall for some specific one protocol, but not have permission to delegate that permission.
反过来，颁发证书，将此权限委托给其每个下属。这个过程将反复进行，直到某个被征召的人获得针对某个特定协议的穿透该防火墙的权限，但没有授权该权限。
The certificate structure generated would reflect the organization structure of the entire Defense Department, just as the nested ACLs would have, but the control of these certificates (via their issuance and revocation) is distributed and need not show up in that one firewall or be replicated in all firewalls. Each individual delegator of permission performs a simple task, well understood. The application software to allow that delegation is correspondingly simple.
生成的证书结构将反映整个国防部的组织结构，就像嵌套的ACL一样，但这些证书的控制（通过证书的颁发和吊销）是分布式的，不需要在一个防火墙中显示，也不需要在所有防火墙中复制。每个单独的权限委托人都执行一项简单的任务，这是很容易理解的。允许这种委托的应用软件也相应地简单。
A certificate, or an ACL entry, has optional validity conditions. The traditional ones are validity dates: not-before and not-after. The SPKI group resolved, in discussion, that on-line tests of various kinds are also validity conditions. That is, they further refine the valid date range of a certificate. Three kinds of on-line tests are envisioned: CRL, re-validation and one-time.
证书或ACL条目具有可选的有效性条件。传统的是有效期：不是在之前也不是之后。SPKI小组在讨论中决定，各种在线测试也是有效性条件。也就是说，它们进一步细化了证书的有效日期范围。设想了三种在线测试：CRL、再验证和一次性测试。
When validity confirmation is provided by some online test, then the issuer of those refinements need not be the issuer of the original certificate. In many cases, the business or security model for the two issuers is different. However, in SPKI, the certificate issuer must specify the issuer of validity confirmations.
当通过某些在线测试提供有效性确认时，这些改进的颁发者不必是原始证书的颁发者。在许多情况下，两个发行人的业务或安全模式是不同的。但是，在SPKI中，证书颁发者必须指定有效性确认的颁发者。
An early form of CRL [Certificate Revocation List] was modeled after the news print book that used to be kept at supermarket checkout stands. Those books held lists of bad checking account numbers and, later, bad credit card numbers. If one's payment instrument wasn't listed in the book, then that instrument was considered good.
CRL（证书撤销列表）的早期形式是仿照过去存放在超市收银台上的新闻印刷本。这些帐簿上有一系列坏支票账号，后来又有坏信用卡账号。如果一个人的支付工具没有列在账簿中，那么该工具被认为是好的。
These books would be issued periodically, and delivered by some means not necessarily taking a constant time. However, when a new book arrived, the clerk would replace the older edition with the new one and start using it. This design was suited to the constraints of the implementation: use of physical books, delivered by physical means. The book held bad account numbers rather than good ones because the list of bad accounts was smaller.
这些书将定期发行，并通过某种方式交付，不一定需要固定的时间。然而，当一本新书到达时，店员会用新的替换旧的版本并开始使用它。这种设计适合于实现的约束：使用物理书籍，通过物理方式交付。这本书里有坏帐，而不是好帐，因为坏帐的清单较小。
An early CRL design followed this model. It had a list of revoked certificate identifiers. It also had a sequence number, so that one could tell which of two CRLs was more recent. A newer CRL would replace an older one.
早期的CRL设计遵循这种模式。它有一个已吊销证书标识符的列表。它还有一个序列号，这样人们就可以知道两个CRL中哪一个是最近的。新的CRL将取代旧的CRL。
This mode of operation is like wandering anti-matter. When the issuer wants to revoke a certificate, it is listed in the next CRL to go out. If the revocation is urgent, then that CRL can be released immediately. The CRL then follows some dissemination process unrelated to the needs of the consumers of the CRL. If the CRL encounters a certificate it has listed, it effectively annihilates that certificate. If it encounters an older CRL, it annihilates that CRL also, leaving a copies of itself at the verifiers it encounters.
这种运作模式就像是反物质的游荡。当颁发者想要撤销证书时，它将列在下一个要退出的CRL中。如果撤销是紧急的，则可以立即释放该CRL。然后，CRL遵循与CRL消费者需求无关的传播过程。如果CRL遇到它列出的证书，它将有效地消除该证书。如果它遇到一个较旧的CRL，它也会消除该CRL，在它遇到的验证器上留下一个自身的副本。
However, this process is non-deterministic. The result of the authorization computation is at least timing dependent. Given an active adversary, it can also be a security hole. That is, an adversary can prevent revocation of a given certificate by preventing the delivery of new CRLs. This does not require cryptographic level effort, merely network tampering.
然而，这个过程是不确定的。授权计算的结果至少依赖于时间。如果有一个积极的对手，它也可能是一个安全漏洞。也就是说，对手可以通过阻止新CRL的交付来阻止撤销给定证书。这不需要加密级别的工作，只需要网络篡改。
SPKI has ruled out the use of wandering anti-matter CRLs for its certificates. Every authorization computation is deterministic, under SPKI rules.
SPKI已排除在其证书中使用漫游反物质CRL。根据SPKI规则，每个授权计算都是确定性的。
SPKI permits use of timed CRLs. That is, if a certificate can be referenced in a CRL, then the CRL process is subject to three conditions.
SPKI允许使用定时CRL。也就是说，如果证书可以在CRL中引用，那么CRL过程受三个条件的约束。
1. The certificate must list the key (or its hash) that will sign the CRL and may give one or more locations where that CRL might be fetched.
1. 证书必须列出将对CRL进行签名的密钥（或其散列），并可能给出获取CRL的一个或多个位置。
2. The CRL must carry validity dates.
2. CRL必须带有有效日期。
3. CRL validity date ranges must not intersect. That is, one may not issue a new CRL to take effect before the expiration of the CRL currently deployed.
3. CRL有效日期范围不得相交。也就是说，在当前部署的CRL到期之前，不能发布新的CRL以使其生效。
Under these rules, no certificate that might use a CRL can be processed without a valid CRL and no CRL can be issued to show up as a surprise at the verifier. This yields a deterministic validity computation, independent of clock skew, although clock inaccuracies in the verifier may produce a result not desired by the issuer. The CRL in this case is a completion of the certificate, rather than a message to the world announcing a change of mind.
根据这些规则，如果没有有效的CRL，就不能处理任何可能使用CRL的证书，也不能颁发任何CRL来让验证者感到意外。这产生了与时钟偏移无关的确定性有效性计算，尽管验证器中的时钟不准确可能产生发卡机构不期望的结果。在这种情况下，CRL是证书的完成，而不是向全世界宣布改变想法的信息。
Since CRLs might get very large and since they tend to grow monotonically, one might want to issue changes to CRLs rather than full ones. That is, a CRL might be a full CRL followed by a sequence of delta-CRLs. That sequence of instruments is then treated as a current CRL and the combined CRL must follow the conditions listed above.
由于CRL可能会变得非常大，而且它们往往是单调增长的，因此可能需要对CRL进行更改，而不是对完整的CRL进行更改。也就是说，CRL可能是一个完整的CRL，后跟一系列增量CRL。然后将该仪器序列视为当前CRL，组合CRL必须符合上述条件。
CRLs are negative statements. The positive version of a CRL is what we call a revalidation. Typically a revalidation would list only one certificate (the one of interest), although it might list a set of certificates (to save digital signature effort).
CRL是否定的陈述。CRL的正面版本就是我们所说的重新验证。通常，重新验证只会列出一个证书（感兴趣的证书），尽管它可能会列出一组证书（以节省数字签名工作）。
As with the CRL, SPKI demands that this process be deterministic and therefore that the revalidation follow the same rules listed above (in section 5.2).
与CRL一样，SPKI要求该过程具有确定性，因此重新验证遵循上述相同规则（第5.2节）。
Both timed CRLs and timed revalidations have non-0 validity intervals. To set this validity interval, one must answer the question: "How long are you willing to let the world believe and act on a statement you know to be false?"
定时CRL和定时重新验证的有效期间隔均为非0。要设定这个有效期，你必须回答这样一个问题：“你愿意让世界相信一个你知道是错误的陈述并采取行动多久？”
That is, one must assume that the previous CRL or revalidation has just been signed and transmitted to at least one consumer, locking up a time slot. The next available time slot starts after this validity interval ends. That is the earliest one can revoke a certificate one learns to be false.
也就是说，必须假设之前的CRL或重新验证刚刚被签名并传输给至少一个消费者，锁定了一个时隙。下一个可用的时隙在此有效期间隔结束后开始。这是一个人最早可以撤销一个他知道是假的证书。
The answer to that question comes from risk management. It will probably be based on expected monetary losses, at least in commercial cases.
这个问题的答案来自风险管理。这可能是基于预期的货币损失，至少在商业案例中是如此。
Validity intervals of length zero are not possible. Since transmission takes time, by the time a CRL was received by the verifier, it would be out of date and unusable. That assumes perfect clock synchronization. If clock skew is taken into consideration, validity intervals need to be that much larger to be meaningful.
长度为零的有效间隔是不可能的。由于传输需要时间，当验证者收到CRL时，CRL将过时且无法使用。这假设了完美的时钟同步。如果考虑时钟偏差，有效性间隔需要大得多才能有意义。
For those who want to set the validity interval to zero, SPKI defines a one-time revalidation.
对于那些希望将有效期间隔设置为零的人，SPKI定义了一次性重新验证。
This form of revalidation has no lifetime beyond the current authorization computation. One applies for this on-line, one-time revalidation by submitting a request containing a nonce. That nonce gets returned in the signed revalidation instrument, in order to prevent replay attacks. This protocol takes the place of a validity date range and represents a validity interval of zero, starting and ending at the time the authorization computation completes.
这种形式的重新验证没有超出当前授权计算的生存期。可以通过提交包含nonce的请求来申请此在线一次性重新验证。该nonce将在签名的重新验证工具中返回，以防止重播攻击。该协议取代有效日期范围，表示零的有效期间隔，从授权计算完成时开始和结束。
A performance analysis of the various methods of achieving fine-grain control over the validity interval of a certificate should consider the possibility of just making the original certificate short-lived, especially if the online test result is issued by the same key that issued the certificate. There are cases in which the short-lived certificate requires fewer signatures and less network traffic than the various online test options. The use of a short-lived certificate always requires fewer signature verifications than the use of certificate plus online test result.
对实现证书的有效间隔的细粒度控制的各种方法的性能分析应该考虑使原始证书寿命短的可能性，特别是如果在线测试结果由颁发证书的同一密钥发出。在某些情况下，与各种在线测试选项相比，短期证书需要更少的签名和更少的网络流量。与使用证书加在线测试结果相比，使用短期证书通常需要更少的签名验证。
If one wants to issue short-lived certificates, SPKI defines a kind of online test statement to tell the user of the certificate where a replacement short-lived certificate might be fetched.
如果想要颁发短期证书，SPKI定义了一种在线测试语句，告诉证书用户在哪里可以获取替换的短期证书。
There are other possibilities to be considered when choosing a validity condition model to use.
在选择要使用的有效性条件模型时，还需要考虑其他可能性。
Silvio Micali has patented a mechanism for using hash chains to revalidate or revoke a certificate inexpensively. This mechanism changes the performance requirements of those models and might therefore change the conclusion from a performance analysis [ECR].
Silvio Micali已经申请了一种机制的专利，该机制使用哈希链以低成本重新验证或撤销证书。该机制改变了这些模型的性能要求，因此可能会改变性能分析[ECR]得出的结论。
Ron Rivest has written a paper [R98] suggesting that the whole validity condition model is flawed because it assumes that the issuer (or some entity to which it delegates this responsibility) decides the conditions under which a certificate is valid. That traditional model is consistent with a military key management model, in which there is some central authority responsible for key release and for determining key validity.
Ron Rivest撰写了一篇论文[R98]，指出整个有效性条件模型存在缺陷，因为它假设发行人（或其委托的某个实体）决定证书有效的条件。该传统模型与军事密钥管理模型一致，在军事密钥管理模型中，有一些中央机构负责密钥发布和确定密钥有效性。
However, in the commercial space, it is the verifier and not the issuer who is taking a risk by accepting a certificate. It should therefore be the verifier who decides what level of assurance he needs before accepting a credential. That verifier needs information from the issuer, and the more recent that information the better, but the decision is the verifier's in the end.
然而，在商业领域，接受证书的风险是验证人而不是发行人。因此，在接受凭证之前，应由验证者决定他需要何种程度的保证。验证者需要来自发行者的信息，信息越新越好，但最终决定权在验证者。
This line of thought deserves further consideration, but is not reflected in the SPKI structure definition. It might even be that both the issuer and the verifier have stakes in this decision, so that any replacement validity logic would have to include inputs from both.
这一思路值得进一步考虑，但并未反映在SPKI结构定义中。甚至可能是发行人和验证者在这个决定中都有利害关系，因此任何替换有效性逻辑都必须包括来自两者的输入。
The processing of certificates and related objects to yield an authorization result is the province of the developer of the application or system. The processing plan presented here is an example that may be followed, but its primary purpose is to clarify the semantics of an SPKI certificate and the way it and various other kinds of certificate might be used to yield an authorization result.
证书和相关对象的处理以产生授权结果是应用程序或系统开发人员的职责。这里提供的处理计划是一个可以遵循的示例，但其主要目的是澄清SPKI证书的语义，以及使用SPKI证书和其他各种证书生成授权结果的方式。
There are three kinds of entity that might be input to the computation that yields an authorization result:
有三种类型的实体可以输入到生成授权结果的计算中：
1. <name,key> (as a certificate)
1. <name，key>（作为证书）
2. <authorization,name> (as an attribute certificate or ACL entry)
2. <authorization，name>（作为属性证书或ACL条目）
3. <authorization,key> (as an authorization certificate or ACL entry)
3. <authorization，key>（作为授权证书或ACL条目）
These entities are processed in three stages.
这些实体分三个阶段处理。
1. Individual certificates are verified by checking their signatures and possibly performing other work. They are then mapped to intermediate forms, called "tuples" here.
1. 通过检查个人证书的签名并可能执行其他工作来验证个人证书。然后将它们映射到中间形式，这里称为“元组”。
The other work for SPKI or SDSI certificates might include processing of on-line test results (CRL, re-validation or one-time validation).
SPKI或SDSI证书的其他工作可能包括处理在线测试结果（CRL、重新验证或一次性验证）。
The other work for PGP certificates may include a web-of-trust computation.
PGP证书的其他工作可能包括信任计算网络。
The other work for X.509 certificates depends on the written documentation for that particular use of X.509 (typically tied to the root key from which the certificate descended) and could
X.509证书的其他工作取决于X.509的特定用途的书面文档（通常与证书派生的根密钥绑定），并且可以
involve checking information in the parent certificate as well as additional information in extensions of the certificate in question. That is, some use X.509 certificates just to define names. Others use X.509 to communicate an authorization implicitly (e.g., SSL server certificates). Some might define extensions of X.509 to carry explicit authorizations. All of these interpretations are specified in written documentation associated with the certificate chain and therefore with the root from which the chain descends.
包括检查父证书中的信息以及相关证书扩展中的附加信息。也就是说，有些人使用X.509证书只是为了定义名称。其他人使用X.509隐式传递授权（例如SSL服务器证书）。有些人可能会定义X.509的扩展来携带显式授权。所有这些解释都是在与证书链相关的书面文档中指定的，因此与证书链的根相关。
If on-line tests are involved in the certificate processing, then the validity dates of those on-line test results are intersected by VIntersect() [defined in 6.3.2, below] with the validity dates of the certificate to yield the dates in the certificate's tuple(s).
如果证书处理中涉及在线测试，则这些在线测试结果的有效日期由VIntersect（）[定义见下文6.3.2]与证书的有效日期相交，以生成证书元组中的日期。
2. Uses of names are replaced with simple definitions (keys or hashes), based on the name definitions available from reducing name 4-tuples.
2. 名称的使用将替换为简单定义（键或散列），该定义基于可从精简名称4元组获得的名称定义。
3. Authorization 5-tuples are then reduced to a final authorization result.
3. 然后将授权5元组缩减为最终授权结果。
The 5-tuple is an intermediate form, assumed to be held in trusted memory so that it doesn't need a digital signature for integrity. It is produced from certificates or other credentials via trusted software. Its contents are the same as the contents of an SPKI certificate body, but it might be derived from another form of certificate or from an ACL entry.
5元组是一种中间形式，假定它保存在可信内存中，因此不需要数字签名来保证完整性。它是通过可信软件从证书或其他凭据生成的。它的内容与SPKI证书正文的内容相同，但它可能来自另一种形式的证书或ACL条目。
The elements of a 5-tuple are:
五元组的元素包括：
1. Issuer: a public key (or its hash), or the reserved word "Self". This identifies the entity speaking this intermediate result.
1. 颁发者：公钥（或其散列），或保留字“Self”。这将标识说出此中间结果的实体。
2. Subject: a public key (or its hash), a name used to identify a public key, the hash of an object or a threshold function of subordinate subjects. This identifies the entity being spoken about in this intermediate result.
2. 主题：公钥（或其散列）、用于标识公钥的名称、对象的散列或从属主题的阈值函数。这标识了在这个中间结果中谈论的实体。
3. Delegation: a boolean. If TRUE, then the Subject is permitted by the Issuer to further propagate the authorization in this intermediate result.
3. 委托：布尔值。如果为TRUE，则发行人允许主题在该中间结果中进一步传播授权。
4. Authorization: an S-expression. [Rules for combination of Authorizations are given below.]
4. 授权：一个S表达式。[授权组合规则如下所示。]
5. Validity dates: a not-before date and a not-after date, where "date" means date and time. If the not-before date is missing from the source credential then minus infinity is assumed. If the not-after date is missing then plus infinity is assumed.
5. 有效日期：不在日期之前和之后，其中“日期”是指日期和时间。如果源凭证中缺少not before日期，则假定为负无穷大。如果不晚于日期缺失，则假定为正无穷大。
A <name,key> certificate (such as X.509v1 or SDSI 1.0) carries no authorization field but does carry a name. Since it is qualitatively different from an authorization certificate, a separate intermediate form is defined for it.
<name，key>证书（如X.509v1或SDSI 1.0）不带授权字段，但带名称。由于它与授权证书在性质上不同，因此为其定义了单独的中间形式。
The elements of a Name 4-tuple are:
名称4元组的元素包括：
1. Issuer: a public key (or its hash). This identifies the entity defining this name in its private name space.
1. 颁发者：公钥（或其散列）。这将标识在其专用名称空间中定义此名称的实体。
2. Name: a byte string
2. 名称：一个字节字符串
3. Subject: a public key (or its hash), a name, or a threshold function of subordinate subjects. This defines the name.
3. 主题：一个公钥（或其散列）、一个名称或从属主题的阈值函数。这定义了名称。
4. Validity dates: a not-before date and a not-after date, where "date" means date and time. If the not-before date is missing from the source credential then minus infinity is assumed. If the not-after date is missing then plus infinity is assumed.
4. 有效日期：不在日期之前和之后，其中“日期”是指日期和时间。如果源凭证中缺少not before日期，则假定为负无穷大。如果不晚于日期缺失，则假定为正无穷大。
The two 5-tuples:
两个5元组：
<I1,S1,D1,A1,V1> + <I2,S2,D2,A2,V2>
<I1,S1,D1,A1,V1> + <I2,S2,D2,A2,V2>
yield
产量
<I1,S2,D2,AIntersect(A1,A2),VIntersect(V1,V2)>
<I1,S2,D2,AIntersect(A1,A2),VIntersect(V1,V2)>
provided
假如
the two intersections succeed,
两个十字路口成功，
S1 = I2
S1 = I2
and
和
D1 = TRUE
D1 = TRUE
If S1 is a threshold subject, there is a slight modification to this rule, as described below in section 6.3.3.
如果S1是阈值对象，则对该规则进行轻微修改，如下文第6.3.3节所述。
An authorization is a list of strings or sub-lists, of meaning to and probably defined by the application that will use this authorization for access control. Two authorizations intersect by matching, element for element. If one list is longer than the other but match at all elements where both lists have elements, then the longer list is the result of the intersection. This means that additional elements of a list must restrict the permission granted.
授权是字符串或子列表的列表，对将使用此授权进行访问控制的应用程序有意义，并且可能由其定义。两个授权通过元素对元素的匹配相交。如果一个列表比另一个列表长，但在两个列表都有元素的所有元素上都匹配，则较长的列表是相交的结果。这意味着列表的其他元素必须限制授予的权限。
Although actual authorization string definitions are application dependent, AIntersect provides rules for automatic intersection of these strings so that application developers can know the semantics of the strings they use. Special semantics would require special reduction software.
虽然实际的授权字符串定义依赖于应用程序，但AIntersect提供了这些字符串的自动交集规则，以便应用程序开发人员可以知道他们使用的字符串的语义。特殊的语义需要特殊的简化软件。
For example, there might be an ftpd that allows public key access control, using authorization certificates. Under that service,
例如，可能有一个ftpd，它允许使用授权证书进行公钥访问控制。在这项服务下，
(ftp (host ftp.clark.net))
（ftp（主机ftp.clark.net））
might imply that the keyholder would be allowed ftp access to all directories on ftp.clark.net, with all kinds of access (read, write, delete, ...). This is more general (allows more access) than
可能意味着密钥持有者可以通过ftp访问ftp.clark.net上的所有目录，并具有各种访问权限（读、写、删除等）。这比
(ftp (host ftp.clark.net) (dir /pub/cme))
（ftp（主机ftp.clark.net）（dir/pub/cme））
which would allow all kinds of access but only in the directory specified. The intersection of the two would be the second.
这将允许所有类型的访问，但仅在指定的目录中。两者的交叉点将是第二个。
Since the AIntersect rules imply position dependency, one could also define the previous authorization string as:
由于AIntersect规则暗示位置依赖性，因此还可以将以前的授权字符串定义为：
(ftp ftp.clark.net /pub/cme)
（ftp.clark.net/pub/cme）
to keep the form compact.
保持表格紧凑。
To allow for wild cards, there are a small number of special S-expressions defined, using "*" as the expression name.
为了允许通配符，定义了少量特殊的S表达式，使用“*”作为表达式名称。
(*) stands for the set of all S-expressions and byte-strings. In other words, it will match anything. When intersected with anything, the result is that other thing. [The AIntersect rule about lists of different length treats a
（*）表示所有S表达式和字节字符串的集合。换句话说，它将匹配任何东西。当与任何事物相交时，结果是另一事物。[关于不同长度列表的ainterspect规则将
list as if it had enough (*) entries implicitly appended to it to match the length of another list with which it was being intersected.]
列表，就好像它有足够多的（*）项隐式附加到它，以匹配与之相交的另一个列表的长度。]
(* set <tag-expr>*) stands for the set of elements listed in the *-form.
（*set<tag expr>*）表示*表单中列出的元素集。
(* prefix <byte-string>) stands for the set of all byte strings that start with the one given in the *-form.
（*前缀<byte string>）表示所有字节字符串的集合，这些字节字符串以*-形式中给定的字节字符串开头。
(* range <ordering> <lower-limit>? <upper-limit>?) stands for the set of all byte strings lexically (or numerically) between the two limits. The ordering parameter (alpha, numeric, time, binary, date) specifies the kind of strings allowed.
（*range<ordering><lower limit>？<upper limit>？）表示两个限制之间所有字节字符串的词汇（或数字）集。排序参数（字母、数字、时间、二进制、日期）指定允许的字符串类型。
AIntersect() is normal set intersection, when *-forms are defined as they are above and a normal list is taken to mean all lists that start with those elements. The following examples should give a more concrete explanation for those who prefer an explanation without reference to set operations.
AIntersect（）是标准集交集，当*-形式被定义为上面的形式时，一个标准列表表示所有以这些元素开头的列表。下面的示例应该为那些喜欢不参考集合操作的解释的人提供更具体的解释。
AIntersect( (tag (ftp ftp.clark.net cme (* set read write))), (tag (*)) )
AIntersect（（标记（ftp.clark.net cme（*设置读写）），（标记（*））
evaluates to (tag (ftp ftp.clark.net cme (* set read write)))
计算结果为（标记（ftp.clark.net cme（*设置读写）））
AIntersect( (tag (* set read write (foo bla) delete)), (tag (* set write read) ) )
AIntersect（（标记（*设置读写（foo-bla）删除）），（标记（*设置写读）））
evaluates to (tag (* set read write))
计算结果为（标记（*设置读写））
AIntersect( (tag (* set read write (foo bla) delete)), (tag read ) )
AIntersect（（标记（*设置读写（foo-bla）删除）），（标记读取））
evaluates to (tag read)
计算结果为（标记读取）
AIntersect( (tag (* prefix http://www.clark.net/pub/)),
(tag (* prefix http://www.clark.net/pub/cme/html/)) )
AIntersect( (tag (* prefix http://www.clark.net/pub/)),
(tag (* prefix http://www.clark.net/pub/cme/html/)) )
evaluates to (tag (* prefix http://www.clark.net/pub/cme/html/))
evaluates to (tag (* prefix http://www.clark.net/pub/cme/html/))
AIntersect( (tag (* range numeric ge #30# le #39# )), (tag #26#) )
AIntersect( (tag (* range numeric ge #30# le #39# )), (tag #26#) )
fails to intersect.
无法相交。
Date range intersection is straight-forward.
日期范围交叉点是直行的。
V = VIntersect( X, Y )
V=横截面（X，Y）
is defined as
定义为
Vmin = max( Xmin, Ymin )
Vmin=最大值（Xmin，Ymin）
Vmax = min( Xmax, Ymax )
Vmax=min（Xmax，Ymax）
and if Vmin > Vmax, then the intersection failed.
如果Vmin>Vmax，则交叉点失败。
These rules assume that daytimes are expressed in a monotonic form, as they are in SPKI.
这些规则假设日时间是以单调的形式表示的，就像它们在SPKI中一样。
The full SPKI VIntersect() also deals with online tests. In the most straight-forward implementation, each online test to which a certificate is subject is evaluated. Each such test carries with it a validity interval, in terms of dates. That validity interval is intersected with any present in the certificate, to yield a new, current validity interval.
完整的SPKI VIntersect（）还处理在线测试。在最直接的实现中，将对证书所接受的每个在线测试进行评估。每项测试都有一个有效期，以日期为单位。该有效期间隔与证书中的任何内容相交，以生成新的当前有效期间隔。
It is possible for an implementation of VIntersect() to gather up online tests that are present in each certificate and include the union of all those tests in the accumulating tuples. In this case, the evaluation of those online tests is deferred until the end of the process. This might be appropriate if the tuple reduction is being performed not for answering an immediate authorization question but rather for generation of a summary certificate (Certificate Result Certificate) that one might hope would be useful for a long time.
VIntersect（）的实现可以收集每个证书中存在的在线测试，并在累积元组中包含所有这些测试的联合。在这种情况下，这些在线测试的评估将推迟到过程结束。如果执行元组缩减不是为了回答即时授权问题，而是为了生成一个摘要证书（证书结果证书），则这可能是合适的，人们可能希望该证书在很长一段时间内有用。
A threshold subject is specified by two numbers, K and N [0<K<=N], and N subordinate subjects. A threshold subject is reduced to a single subject by selecting K of the N subjects and reducing each of those K to the same subject, through a sequence of certificates. The (N-K) unselected subordinate subjects are set to (null).
阈值主题由两个数字指定，K和N[0<K<=N]以及N个从属主题。通过选择N个主题中的K个，并通过证书序列将这些K个主题中的每一个减少到同一主题，将阈值主题减少到单个主题。（N-K）个未选择的从属主题设置为（null）。
The intermediate form for a threshold subject is a copy of the tuple in which the threshold subject appears, but with only one of the subordinate subjects. Those subordinate tuples are reduced individually until the list of subordinate tuples has (N-K) (null) entries and K entries with the same subject. At that point, those K tuples are validity-, authorization- and delegation- intersected to yield the single tuple that will replace the list of tuples.
阈值主题的中间形式是出现阈值主题的元组的副本，但只有一个从属主题。这些下级元组将被单独缩减，直到下级元组列表中有（N-K）（null）个条目和具有相同主题的K个条目。在这一点上，这些K元组是有效性、授权和委托的交叉部分，以生成将替换元组列表的单个元组。
All reduction operations are in the order provided by the prover. That simplifies the job of the verifier, but leaves the job of finding the correct list of reductions to the prover.
所有还原操作均按照校准仪提供的顺序进行。这简化了验证器的工作，但将查找正确的缩减列表的工作留给了验证器。
The general algorithm for finding the right certificate paths from a large set of unordered certificates has been solved[ELIEN], but might be used only rarely. Each keyholder who is granted some authority should receive a sequence of certificates delegating that authority. That keyholder may then want to delegate part of this authority on to some other keyholder. To do that, a single additional certificate is generated and appended to the sequence already available, yielding a sequence that can be used by the delegatee to prove access permission.
从大量无序证书中查找正确证书路径的通用算法已经解决[ELIEN]，但可能很少使用。每个被授予某种权限的密钥持有者都应该收到一系列授予该权限的证书。然后，该钥匙持有人可能希望将该授权的一部分委托给其他钥匙持有人。为此，将生成一个附加证书并将其附加到已经可用的序列中，从而生成一个序列，该序列可供被委派者用于证明访问权限。
There will be name 4-tuples in two different classes, those that define the name as a key and those that define the name as another name.
在两个不同的类中会有名称4元组，一个将名称定义为键，另一个将名称定义为另一个名称。
1. [(name K1 N) -> K2]
1. [(name K1 N) -> K2]
2. [(name K1 N) -> (name K2 N1 N2 ... Nk)]
2. [(name K1 N) -> (name K2 N1 N2 ... Nk)]
As with the 5-tuples discussed in the previous section, name definition 4-tuples should be delivered in the order needed by the prover. In that case, the rule for name reduction is to replace the name just defined by its definition. For example,
与上一节讨论的5元组一样，名称定义4元组应按照验证程序所需的顺序交付。在这种情况下，名称缩减的规则是替换刚由其定义定义的名称。例如
(name K1 N N1 N2 N3) + [(name K1 N) -> K2]
(name K1 N N1 N2 N3) + [(name K1 N) -> K2]
-> (name K2 N1 N2 N3)
->（名称K2 N1 N2 N3）
or, in case 2 above,
或者，在上述情况2中，
(name K1 N Na Nb Nc) + [(name K1 N) -> (name K2 N1 N2 ... Nk)]
(name K1 N Na Nb Nc) + [(name K1 N) -> (name K2 N1 N2 ... Nk)]
-> (name K2 N1 N2 ... Nk Na Nb Nc)
->（名称K2 N1 N2…Nk Na Nb Nc）
With the second form of name definition, one might have names that temporarily grow. If the prover is providing certificates in order, then the verifier need only do as it is told.
使用第二种形式的名称定义，可能会有临时增长的名称。如果验证人按顺序提供证书，那么验证人只需按要求执行即可。
If the verifier is operating from an unordered pool of tuples, then a safe rule for name reduction is to apply only those 4-tuples that define a name as a key. Such applications should bring 4-tuples that started out in class (2) into class (1), and eventually reduce all names to keys. Any naming loops are avoided by this process.
如果验证器是从无序的元组池中操作的，那么名称缩减的安全规则是只应用那些将名称定义为键的4元组。此类应用程序应该将从类（2）开始的4元组引入类（1），并最终将所有名称缩减为键。此过程避免了任何命名循环。
Some of a threshold subject's subordinate subjects might be names. Those names must be reduced by application of 4-tuples. The name reduction process proceeds independently on each name in the subordinate subject as indicated in 6.3.3 above.
阈值主题的一些从属主题可能是名称。这些名称必须通过应用4元组来减少。如上文第6.3.3条所述，姓名缩减过程在从属主题中的每个姓名上独立进行。
One can reduce individual named subjects in a threshold subject and leave the subject in threshold form, if one desires. There is no delegation- or authorization-intersection involved, only a validity-intersection during name reduction. This might be used by a service that produces Certificate Result Certificates [see 6.7].
如果愿意的话，可以将个体命名的主体减少为阈值主体，并将主体保留为阈值形式。在名称缩减期间，不涉及委托或授权交集，只涉及有效性交集。这可能由生成证书结果证书的服务使用[请参见6.7]。
Whenever a 4-tuple is used to reduce the subject (or part of the subject) of another tuple, its validity interval is intersected with that of the tuple holding the subject being reduced and the intersection is used in the resulting tuple. Since a 4-tuple contains no delegation or authorization fields, the delegation permission and authorization of the tuple being acted upon does not change.
当一个4元组用于减少另一个元组的主题（或主题的一部分）时，其有效性区间与包含被减少主题的元组的有效性区间相交，并在结果元组中使用该相交。由于4元组不包含委派或授权字段，因此所操作的元组的委派权限和授权不会更改。
Any certificate currently defined, as well as ACL entries and possibly other instruments, can be translated to 5-tuples (or name tuples) and therefore take part in an authorization computation. The specific rules for those are given below.
当前定义的任何证书，以及ACL条目和可能的其他工具，都可以转换为5元组（或名称元组），从而参与授权计算。具体规则如下所示。
The original X.509 certificate is a <name,key> certificate. It translates directly to a name tuple. The form
原始X.509证书是<name，key>证书。它直接转换为名称元组。形式
[Kroot, (name <leaf-name>), K1, validity]
[Kroot，（名称<叶名>），K1，有效期]
is used if the rules for that particular X.509 hierarchy is that all leaf names are unique, under that root. If uniqueness of names applies only to individual CAs in the X.509 hierarchy, then one must generate
如果特定X.509层次结构的规则是该根下的所有叶名称都是唯一的，则使用。如果名称的唯一性仅适用于X.509层次结构中的单个CA，则必须生成
[Kroot, (name CA1 CA2 ... CAk <leaf-name>), K1, validity]
[Kroot，（名称CA1 CA2…CAk<leaf name>），K1，有效期]
after verifying the certificate chain by the rules appropriate to that particular chain.
通过适用于该特定链的规则验证证书链之后。
A PGP certificate is a <name,key> certificate. It is verified by web-of-trust rules (as specified in the PGP documentation). Once verified, it yields name tuples of the form
PGP证书是<name，key>证书。它由信任网规则（如PGP文档中所述）进行验证。一旦验证，它将生成表单的名称元组
[Ki, name, K1, validity]
[Ki，名称，K1，有效期]
where Ki is a key that signed that PGP (UserID,key) pair. There would be one tuple produced for each signature on the key, K1.
其中Ki是签署该PGP（用户ID，密钥）对的密钥。密钥K1上的每个签名都会产生一个元组。
An X.509v3 certificate may be used to declare a name. It might also declare explicit authorizations, by way of extensions. It might also declare an implicit authorization of the form (tag (*)). The actual set of tuples it yields depends on the documentation associated with that line of certificates. That documentation could conceptually be considered associated with the root key of the certificate chain. In addition, some X.509v3 certificates (such as those used for SET), have defined extra validity tests for certificate chains depending on custom extensions. As a result, it is likely that X.509v3 chains will have to be validated independently, by chain validation code specific to each root key. After that validation, that root-specific code can then generate the appropriate multiple tuples from the one certificate.
X.509v3证书可用于声明名称。它还可以通过扩展声明显式授权。它还可以声明表单的隐式授权（标记（*））。它产生的实际元组集取决于与该行证书关联的文档。从概念上讲，可以认为该文档与证书链的根密钥相关联。此外，一些X.509v3证书（例如用于SET的证书）根据自定义扩展为证书链定义了额外的有效性测试。因此，X.509v3链很可能必须通过特定于每个根键的链验证代码进行独立验证。验证之后，特定于根的代码可以从一个证书生成适当的多个元组。
An X9.57 attribute certificate should yield one or more 5-tuples, with names as Subject. The code translating the attribute certificate will have to build a fully-qualified name to represent the Distinguished Name in the Subject. For any attribute certificates that refer to an ID certificate explicitly, the Subject of the 5-tuple can be the key in that ID certificate, bypassing the construction of name 4-tuples.
X9.57属性证书应产生一个或多个5元组，名称作为主题。翻译属性证书的代码必须构建一个完全限定的名称来表示主题中的可分辨名称。对于显式引用ID证书的任何属性证书，5元组的主题可以是该ID证书中的密钥，而不必构造名称4元组。
A SDSI 1.0 certificate maps directly to one 4-tuple.
SDSI 1.0证书直接映射到一个4元组。
An SPKI certificate maps directly to one 4- or 5- tuple, depending respectively on whether it is a name certificate or carries an authorization.
SPKI证书直接映射到一个4元组或5元组，这分别取决于它是名称证书还是带有授权。
An SSL certificate carries a number of authorizations, some implicitly. The authorization:
SSL证书包含许多授权，有些是隐式的。授权书：
(tag (ssl))
（标签（ssl））
is implicit. In addition, the server certificate carries a DNS name parameter to be matched against the DNS name of the web page to which the connection is being made. That might be encoded as:
这是含蓄的。此外，服务器证书带有一个DNS名称参数，该参数将与正在进行连接的网页的DNS名称相匹配。可编码为：
(tag (dns <domain-name>))
（标签（dns<domain name>）
Meanwhile, there is the "global cert" permission -- the permission for a US-supplied browser to connect using full strength symmetric cryptography even though the server is outside the USA. This might be encoded as:
同时，还有“全球证书”权限——允许美国提供的浏览器使用全强度对称加密进行连接，即使服务器在美国境外。这可能被编码为：
(tag (us-crypto))
（标签（美国加密）
There are other key usage attributes that would also be encoded as tag fields, but a full discussion of those fields is left to the examples document.
还有其他一些关键用法属性也可以编码为标记字段，但是这些字段的完整讨论将留给示例文档。
An ACL entry for an SSL root key would have the tag:
SSL根密钥的ACL条目将具有以下标记：
(tag (* set (ssl) (dns (*))))
（标签（*设置（ssl）（dns（*））
which by the rules of intersection is equivalent to:
根据交叉规则，其等同于：
(tag (* set (ssl) (dns)))
（标签（*设置（ssl）（dns）））
unless that root key also had the permission from the US Commerce Department to grant us-crypto permission, in which case the root key would have:
除非该根密钥还获得美国商务部授予美国加密权限的许可，在这种情况下，根密钥将具有：
(tag (* set (ssl) (dns) (us-crypto)))
（标签（*设置（ssl）（dns）（美国加密）））
A CA certificate, used for SSL, would then need only to communicate down its certificate chain those permissions allocated in the ACL. Its tag might then translate to:
然后，用于SSL的CA证书只需要在其证书链上传递在ACL中分配的权限。然后，其标记可能会转换为：
(tag (*))
（标签（*）
A leaf server certificate for the Datafellows server might, for example, have a tag field of the form:
例如，Datafellows服务器的叶服务器证书可能具有以下格式的标记字段：
(tag (* set (ssl) (dns www.datafellows.com)))
（标签（*设置（ssl）（dns www.datafellows.com）））
showing that it was empowered to do SSL and to operate from the given domain name, but not to use US crypto with a US browser.
表明它有权使用SSL并从给定的域名进行操作，但不能在美国浏览器上使用美国加密。
The use of (* set) for the two attributes in this example could have been abbreviated as:
在本例中，两个属性使用（*set）可以缩写为：
(tag (ssl www.datafellows.com))
（标签（ssl www.datafellows.com））
while CA certificates might carry:
而CA证书可能包含：
(tag (ssl (*))) or just (tag (*))
（标记（ssl（*））或仅（标记（*））
but separating them, via (* set), allows for a future enhancement of SSL in which the (ssl) permission is derived from one set of root keys (those of current CAs) while the (dns) permission is derived from another set of root keys (those empowered to speak in DNSSEC) while the (us-crypto) permission might be granted only to a root key belonging to the US Department of Commerce. The three separate tests in the verifying code (e.g., the browser) would then involve separate 5-tuple reductions from separate root key ACL entries.
但是，通过（*set）将它们分开，允许将来对SSL进行增强，其中（SSL）权限来自一组根密钥（当前CA的根密钥），而（dns）权限来自另一组根密钥（授权在DNSSEC中讲话的根密钥），而（us crypto）权限只能授予属于美国商务部的根密钥。验证代码（例如浏览器）中的三个单独测试将涉及从单独的根键ACL条目中单独减少5元组。
The fact that these three kinds of permission are treated as if ANDed is derived from the logic of the code that interprets the permissions and is not expressed in the certificate. That decision is embodied in the authorization code executed by the verifying application.
将这三种权限视为ANDed的事实源自解释权限的代码逻辑，而不是在证书中表示。该决定体现在验证应用程序执行的授权代码中。
Typically, one will reduce a chain of certificates to answer an authorization question in one of two forms:
通常，将减少证书链，以两种形式之一回答授权问题：
1. Is this Subject, S, allowed to do A, under this ACL and with this set of certificates?
1. 是否允许此主题S在此ACL下使用此证书集执行A？
2. What is Subject S allowed to do, under this ACL and with this set of certificates?
2. 在这个ACL下，使用这组证书，允许使用者做什么？
The answer to the second computation can be put into a new certificate issued by the entity doing the computation. That one certificate corresponds to the semantics of the underlying certificates and online test results. We call it a Certificate Result Certificate.
第二次计算的答案可以放入进行计算的实体颁发的新证书中。这一个证书对应于底层证书和在线测试结果的语义。我们称之为证书结果证书。
Cryptographic keys have limited lifetimes. Keys can be stolen. Keys might also be discovered through cryptanalysis. If the theft is noticed, then the key can be replaced as one would replace a credit card. More likely, the theft will not be noticed. To cover this case, keys are replaced routinely.
加密密钥的生命周期有限。钥匙可能会被偷。密钥也可以通过密码分析来发现。如果发现被盗，则可以像更换信用卡一样更换钥匙。更有可能的是，盗窃案不会被注意到。为了解决这个问题，钥匙会定期更换。
The replacement of a key needs to be announced to those who would use the new key. It also needs to be accomplished smoothly, with a minimum of hassle.
需要向使用新钥匙的人宣布钥匙的更换。它也需要顺利完成，以最小的麻烦。
Rather than define a mechanism for declaring a key to be bad or replaced, SPKI defines a mechanism for giving certificates limited lifetimes so that they can be replaced. That is, under SPKI one does not declare a key to be bad but rather stops empowering it and instead empowers some other key. This limitation of a certificate's lifetime might be by limited lifetime at time of issuance or might be via the lifetime acquired through an on-line test (CRL, revalidation or one-time). Therefore, all key lifetime control becomes certificate lifetime control.
SPKI没有定义一种机制来声明密钥是坏的或被替换的，而是定义了一种机制来为证书提供有限的生存期，以便可以替换它们。也就是说，在SPKI下，不会声明一个密钥是坏的，而是停止授权它，而是授权其他密钥。证书生命周期的限制可能是在颁发时的有限生命周期，也可能是通过在线测试（CRL、重新验证或一次性）获得的生命周期。因此，所有密钥生存期控制变为证书生存期控制。
If keyholders had inescapable names [see section 2.5, above], then one could refer to them by those names and define a certificate to map from an inescapable name to the person's current key. That certificate could be issued by any CA, since all CAs would use the inescapable name for the keyholder. The attribute certificates and ACLs that refer to the keyholder would all refer to this one inescapable name.
如果密钥持有者有不可回避的名字[见上文第2.5节]，那么可以通过这些名字来引用他们，并定义一个证书，将不可回避的名字映射到此人的当前密钥。该证书可以由任何CA颁发，因为所有CA都会为密钥持有者使用不可避免的名称。引用密钥持有者的属性证书和ACL都将引用这个不可避免的名称。
However, there are no inescapable names for keyholders. [See section 2.5, above.]
然而，对于钥匙持有者来说，没有不可避免的名字。[见上文第2.5节。]
One could conceivably have a governmental body or other entity that would issue names voluntarily to a keyholder, strictly for the purpose of key management. One would then receive all authorizations through that name. There would have to be only one such authority,
可以想象，有一个政府机构或其他实体将自愿向钥匙持有人发放姓名，严格地用于钥匙管理。然后通过该名称接收所有授权。只有一个这样的权威，
however. Otherwise, names would have to be composed of parts: an authority name and the individual's name. The authority name would, in turn, have to be granted by some single global authority.
然而否则，姓名必须由以下部分组成：机构名称和个人名称。反过来，该机构名称必须由某个单一的全球机构授予。
That authority then becomes able to create keys of its own and certificates to empower them as any individual, and through those false certificates acquire access rights of any individual in the world. Such power is not likely to be tolerated. Therefore, such a central authority is not likely to come to pass.
然后，该机构能够创建自己的密钥和证书，以使其作为任何个人获得授权，并通过这些虚假证书获得世界上任何个人的访问权。这种权力不太可能被容忍。因此，这样一个中央权威不太可能实现。
Instead of inescapable names or single-root naming authorities, we have names assigned by some entity that issues a <name,key> certificate. As noted in sections 2.8 and 2.9, above, such names have no meaning by themselves. They must be fully qualified to have meaning.
我们没有不可避免的名称或单根命名机构，而是由某个颁发<name，key>证书的实体指定名称。如上文第2.8节和第2.9节所述，此类名称本身没有任何意义。它们必须完全有资格具有意义。
Therefore, in the construct:
因此，在构造中：
(name (hash sha1 |TLCgPLFlGTzgUbcaYLW8kGTEnUk=|) jim)
（姓名（hash sha1 | tlcgpllflgtzgubcaylw8kgtenuk=|）jim）
the name is not
名字不是
"jim"
“吉姆”
but rather
而是
"(name (hash sha1 |TLCgPLFlGTzgUbcaYLW8kGTEnUk=|) jim)"
（姓名（hash sha1 | tlcgpllflgtzgubcaylw8kgtenuk=|）jim）
This name includes a public key (through its hash, in the example above). That key has a lifetime like any other key, so this name has not achieved the kind of permanence (free from key lifetimes) that an inescapable name has. However, it appears to be our only alternative.
此名称包括一个公钥（在上面的示例中，通过其哈希）。该密钥与任何其他密钥一样有一个生命周期，因此该名称并没有达到不可避免的名称所具有的那种永久性（没有密钥生命周期）。然而，这似乎是我们唯一的选择。
This name could easily be issued by the named keyholder, for the purpose of key management only. In that case, there is no concern about access control being subverted by some third-party naming authority.
此名称可由指定的密钥持有者轻松发布，仅用于密钥管理。在这种情况下，不必担心访问控制会被某个第三方命名机构破坏。
By the logic above, any name will hang off some public key. The job is then to increase the lifetime of that public key. Once a key lifetime exceeds the expected lifetime of any authorization granted through it, then a succession of new, long-lifetime keys can cover a keyholder forever.
根据上面的逻辑，任何名称都会挂起一些公钥。然后，任务是延长该公钥的生命周期。一旦密钥寿命超过通过其授予的任何授权的预期寿命，则一系列新的、长寿命的密钥可以永远覆盖密钥持有者。
For a key to have a long lifetime, it needs to be strong against cryptanalytic attack and against theft. It should be used only on a trusted machine, running trusted software. It should not be used on an on-line machine. It should be used very rarely, so that the attacker has few opportunities to find the key in the clear where it can be stolen.
要使密钥具有较长的使用寿命，它需要具有强大的抗密码分析攻击和抗盗窃能力。它只能在运行可信软件的可信机器上使用。不应在在线机器上使用。它应该很少使用，这样攻击者就很少有机会在可能被盗的地方找到钥匙。
Different entities will approach this set of requirements in different ways. A private individual, making his own naming root key for this purpose, has the advantage of being too small to invite a well funded attack as compared to the attacks a commercial CA might face.
不同的实体将以不同的方式处理这组需求。与商业CA可能面临的攻击相比，私人用户为此目的制作自己的命名根密钥的优势在于，其规模太小，无法引发资金充足的攻击。
In the limit, one can have one highly protected naming root key for each individual. One might have more than one such key per individual, in order to frustrate attempts to build dossiers, but let us assume only one key for the immediate discussion.
在限制条件下，每个人可以有一个高度保护的命名根密钥。为了阻止建立档案的尝试，每个人可能有不止一个这样的密钥，但是让我们假设只有一个密钥用于立即讨论。
If there is only one name descending from such a key, then one can dispense with the name. Authorizations can be assigned to the key itself, in raw SPKI style, rather than to some name defined under that key. There is no loss of lifetime -- only a change in the subject of the certificate the authorizing key uses to delegate authority.
如果只有一个名字从这样一个键下降，那么可以省去这个名字。授权可以以原始SPKI样式分配给密钥本身，而不是分配给该密钥下定义的某个名称。没有生命周期损失——只是授权密钥用于委托权限的证书主题发生了更改。
However, there is one significant difference, under the SPKI structure. If one delegates some authorization to
然而，在SPKI结构下有一个显著差异。如果有人授权
(name (hash sha1 |TLCgPLFlGTzgUbcaYLW8kGTEnUk=|) carl)
（姓名（hash sha1 | tlcgpllflgtzgubcaylw8kgtenuk=|）carl）
and a different authorization to
以及不同的授权
(hash sha1 |TLCgPLFlGTzgUbcaYLW8kGTEnUk=|)
（hash sha1 | tlcgpllflgtzgubcaylw8kgtenuk=|）
directly, both without granting the permission to delegate, that key can delegate at will through <name,key> certificates in the former case and not delegate at all in the latter case.
在前一种情况下，该密钥可以通过<name，key>证书进行任意委托，而在后一种情况下则完全不进行委托。
In the case of key management, we desire the ability to delegate from a long lived, rarely used key to a shorter lived, often used key -- so in this case, the former mechanism (through a SDSI name) gives more freedom.
在密钥管理的情况下，我们希望能够从一个长寿命、很少使用的密钥委托给一个寿命较短、经常使用的密钥——因此在本例中，前一种机制（通过SDSI名称）提供了更多的自由。
In either of the models above, key |TLCgPLFlGTzgUbcaYLW8kGTEnUk=| will issue a certificate. In the first model, it will be a <name,key> certificate. In the second, it will be an authorization certificate delegating all rights through to the more temporary key.
在上述任一型号中，密钥| TLCgPLFlGTzgUbcaYLW8kGTEnUk=|将颁发证书。在第一个模型中，它将是一个<name，key>证书。在第二种情况下，它将是一个授权证书，将所有权利委托给更临时的密钥。
Either of those certificates might want an on-line validity test. Whether this test is in the form of a CRL, a re-validation or a one-time test, it will be supplied by some entity that is on-line.
这些证书中的任何一个都可能需要在线有效性测试。无论该测试是以CRL、重新验证还是一次性测试的形式进行，都将由在线实体提供。
As the world moves to having all machines on-line all the time, this might be the user's machine. However, until then -- and maybe even after then -- the user might want to hire some service to perform this function. That service could run a 24x7 manned desk, to receive phone calls reporting loss of a key. That authority would not have the power to generate a new key for the user, only to revoke a current one.
随着世界向所有机器一直在线的方向发展，这可能是用户的机器。然而，在那之前——甚至在那之后——用户可能想要雇佣一些服务来执行此功能。这项服务可以运行一个全天候有人值守的办公桌，接收报告钥匙丢失的电话。该机构无权为用户生成新密钥，只能撤销当前密钥。
If, in the worst case, a user loses his master key, then the same process that occurs today with lost wallets would apply. All issuers of authorizations through that master key would need to issue new authorizations through the new master key and, if the old master key had been stolen, cancel all old authorizations through that key.
如果在最坏的情况下，用户丢失了主密钥，那么今天发生的丢失钱包的过程也将适用。通过该主密钥的所有授权颁发者都需要通过新主密钥颁发新授权，如果旧主密钥被盗，则通过该密钥取消所有旧授权。
One can take extraordinary measures to protect root keys and thus increase the lifetimes of those keys. The study of computer fault-tolerance teaches us that truly long lifetimes can be achieved only by redundancy and replacement. Both can be achieved by the use of threshold subjects [section 6.3.3], especially in ACL entries.
可以采取非常措施来保护根密钥，从而延长这些密钥的使用寿命。计算机容错的研究告诉我们，真正的长寿命只能通过冗余和替换来实现。这两种方法都可以通过使用阈值受试者来实现【第6.3.3节】，尤其是在ACL条目中。
If we use a threshold subject in place of a single key subject, in an ACL (or a certificate), then we achieve redundancy immediately. This can be redundancy not only of keys but also of algorithms. That is, the keys in a threshold subject do not need to have the same algorithm.
如果我们在ACL（或证书）中使用阈值主题代替单个密钥主题，那么我们可以立即实现冗余。这不仅是密钥的冗余，也是算法的冗余。也就是说，阈值主题中的密钥不需要具有相同的算法。
Truly long lifetimes come from replacement, not just redundancy. As soon as a component fails (or a key is assumed compromised), it must be replaced.
真正的长寿命来自替换，而不仅仅是冗余。一旦某个组件出现故障（或假定某个密钥被泄露），就必须对其进行更换。
An ACL needs to be access-controlled itself. Assume that the ACL includes an entry with authorization
ACL本身需要进行访问控制。假设ACL包含一个具有授权的条目
(tag (acl-edit))
（标记（acl编辑））
Assume also that what might have been a single root authorization key, K1, is actually a threshold subject
还假设可能是单个根授权密钥K1的内容实际上是一个阈值主题
(k-of-n #03# #07# K1 K2 K3 K4 K5 K6 K7)
(k-of-n #03# #07# K1 K2 K3 K4 K5 K6 K7)
used in any ACL entry granting a normal authorization.
用于授予正常授权的任何ACL条目。
That same ACL could have the subject of an (acl-edit) entry be
同一ACL可以具有（ACL编辑）条目的主题
(k-of-n #05# #07# K1 K2 K3 K4 K5 K6 K7)
(k-of-n #05# #07# K1 K2 K3 K4 K5 K6 K7)
This use of threshold subject would allow the set of root keys to elect new members to that set and retire old members. In this manner, replacement is achieved alongside redundancy and the proper choice of K and N should allow threshold subject key lifetimes approaching infinity.
使用threshold subject将允许根键集为该集选择新成员并使旧成员退役。以这种方式，替换与冗余一起实现，适当选择K和N应允许阈值主题密钥寿命接近无穷大。
There are three classes of information that can be bound together by public key certificates: key, name and authorization. There are therefore three general kinds of certificate, depending on what pair of items the certificate ties together. If one considers the direction of mapping between items, there are six classes: name->key, key->name, authorization->name, name->authorization, authorization->key, key->authorization.
公钥证书可以将三类信息绑定在一起：密钥、名称和授权。因此，根据证书绑定在一起的项目对，有三种一般类型的证书。如果考虑项目之间映射的方向，有六个类：名称->键，键->名称，授权->名称，名称->授权，授权->键，键->授权。
The SPKI working group concluded that the most important use for certificates was access control. Given the various kinds of mapping possible, there are at least two ways to implement access control. One can use a straight authorization certificate:
SPKI工作组得出结论，证书最重要的用途是访问控制。考虑到各种可能的映射，至少有两种方法可以实现访问控制。可以使用直接授权证书：
(authorization->key)
（授权->密钥）
or one can use an attribute certificate and an ID certificate:
或者可以使用属性证书和ID证书：
(authorization->name) + (name->key)
(authorization->name) + (name->key)
There are at least two ways in which the former is more secure than the latter.
至少有两种方式前者比后者更安全。
1. Each certificate has an issuer. If that issuer is subverted, then the attacker can gain access. In the former case, there is only one issuer to trust. In the latter case, there are two.
1. 每个证书都有一个颁发者。如果该颁发者被破坏，则攻击者可以获得访问权限。在前一种情况下，只有一个发行人值得信任。在后一种情况下，有两种情况。
2. In the second case, linkage between the certificates is by name. If the name space of the issuer of the ID certificate is different from the name space of the issuer of the attribute
2. 在第二种情况下，证书之间的链接是通过名称进行的。如果ID证书颁发者的名称空间与属性颁发者的名称空间不同
certificate, then one of the two issuers must use a foreign name space. The process of choosing the appropriate name from a foreign name space is more complex than string matching and might even involve a human guess. It is subject to mistakes. Such a mistake can be made by accident or be guided by an attacker.
证书，则两个颁发者之一必须使用外部名称空间。从外部名称空间中选择合适名称的过程比字符串匹配更复杂，甚至可能需要人工猜测。它容易出错。这样的错误可能是偶然发生的，也可能是攻击者引导的。
This is not to say that one must never use the second construct. If the two certificates come from the same issuer, and therefore with the same name space, then both of the security differentiators above are canceled.
这并不是说我们永远不能使用第二种结构。如果这两个证书来自同一个颁发者，因此具有相同的名称空间，则上述两个安全性差异将被取消。
References
工具书类
[Ab97] Abadi, Martin, "On SDSI's Linked Local Name Spaces", Proceedings of the 10th IEEE Computer Security Foundations Workshop (June 1997).
[Ab97]Abadi，Martin，“关于SDSI的链接本地名称空间”，第十届IEEE计算机安全基础研讨会论文集（1997年6月）。
[BFL] Matt Blaze, Joan Feigenbaum and Jack Lacy, "Distributed Trust Management", Proceedings 1996 IEEE Symposium on Security and Privacy.
[BFL]Matt Blaze、Joan Feigenbaum和Jack Lacy，“分布式信任管理”，1996年IEEE安全和隐私研讨会论文集。
[CHAUM] D. Chaum, "Blind Signatures for Untraceable Payments", Advances in Cryptology -- CRYPTO '82, 1983.
[CHAUM]D.CHAUM，“无法追踪支付的盲签名”，密码学进展——CRYPTO'821983。
[DH] Whitfield Diffie and Martin Hellman, "New Directions in Cryptography", IEEE Transactions on Information Theory, November 1976, pp. 644-654.
[DH]Whitfield Diffie和Martin Hellman，“密码学的新方向”，IEEE信息论交易，1976年11月，第644-654页。
[DvH] J. B. Dennis and E. C. Van Horn, "Programming Semantics for Multiprogrammed Computations", Communications of the ACM 9(3), March 1966.
[DvH]J.B.Dennis和E.C.Van Horn，“多道程序计算的编程语义”，ACM通信9（3），1966年3月。
[ECR] Silvio Micali, "Efficient Certificate Revocation", manuscript, MIT LCS.
[ECR]Silvio Micali，“有效证书撤销”，手稿，麻省理工学院LCS。
[ELIEN] Jean-Emile Elien, "Certificate Discovery Using SPKI/SDSI
2.0 Certificates", Masters Thesis, MIT LCS, May 1998,
<http://theory.lcs.mit.edu/~cis/theses/elien-masters.ps>
[also .pdf and
[ELIEN] Jean-Emile Elien, "Certificate Discovery Using SPKI/SDSI
2.0 Certificates", Masters Thesis, MIT LCS, May 1998,
<http://theory.lcs.mit.edu/~cis/theses/elien-masters.ps>
[also .pdf and
[HARDY] Hardy, Norman, "THE KeyKOS Architecture", Operating Systems Review, v.19 n.4, October 1985. pp 8-25.
[HARDY]HARDY，Norman，“KeyKOS体系结构”，《操作系统评论》，第19卷第4期，1985年10月。第8-25页。
[IDENT] Carl Ellison, "Establishing Identity Without Certification Authorities", USENIX Security Symposium, July 1996.
[IDENT]Carl Ellison，“在没有认证机构的情况下建立身份”，USENIX安全研讨会，1996年7月。
[IWG] McConnell and Appel, "Enabling Privacy, Commerce, Security and Public Safety in the Global Information Infrastructure", report of the Interagency Working Group on Cryptography Policy, May 12, 1996; (quote from paragraph 5 of the Introduction).
[IWG]McConnell和Appel，“在全球信息基础设施中实现隐私、商业、安全和公共安全”，机构间密码政策工作组的报告，1996年5月12日；（引自导言第5段）。
[KEYKOS] Bomberger, Alan, et al., "The KeyKOS(r) Nanokernel Architecture", Proceedings of the USENIX Workshop on Micro-Kernels and Other Kernel Architectures, USENIX Association, April 1992. pp 95-112 (In addition, there are KeyKOS papers on the net available through <http://www.cis.upenn.edu/~KeyKOS/#bibliography>).
[KEYKOS]Bomberger，Alan，et al.，“KEYKOS（r）纳米内核架构”，USENIX微内核和其他内核架构研讨会论文集，USENIX协会，1992年4月。第95-112页（此外，网上还有KeyKOS论文，可通过<http://www.cis.upenn.edu/~KeyKOS/#参考书目>）。
[KOHNFELDER] Kohnfelder, Loren M., "Towards a Practical Public-key Cryptosystem", MIT S.B. Thesis, May. 1978.
[Kohnfeld]Kohnfeld，Loren M.，“迈向实用的公钥密码系统”，麻省理工学院S.B.论文，5月。1978
[LAMPSON] B. Lampson, M. Abadi, M. Burrows, and E. Wobber, "Authentication in distributed systems: Theory and practice", ACM Trans. Computer Systems 10, 4 (Nov. 1992), pp 265-310.
[LAMPSON]B.LAMPSON，M.Abadi，M.Burrows和E.Wobber，“分布式系统中的认证：理论与实践”，ACM Trans。计算机系统10，4（1992年11月），第265-310页。
[LANDAU] Landau, Charles, "Security in a Secure Capability-Based System", Operating Systems Review, Oct 1989 pp 2-4.
[LANDAU]LANDAU，Charles，“基于安全能力的系统中的安全”，操作系统评论，1989年10月，第2-4页。
[LEVY] Henry M. Levy, "Capability-Based Computer Systems", Digital Press, 12 Crosby Dr., Bedford MA 01730, 1984.
[LEVY]Henry M.LEVY，“基于能力的计算机系统”，数字出版社，12 Crosby博士，贝德福德马萨诸塞州01730，1984年。
[LINDEN] T. A. Linden, "Operating System Structures to Support Security and Reliable Software", Computing Surveys 8(4), December 1976.
[LINDEN]T.A.LINDEN，“支持安全和可靠软件的操作系统结构”，计算调查8（4），1976年12月。
[PKCS1] PKCS #1: RSA Encryption Standard, RSA Data Security, Inc., 3 June 1991, Version 1.4.
[PKCS1]PKCS#1:RSA加密标准，RSA数据安全公司，1991年6月3日，版本1.4。
[PKLOGIN] David Kemp, "The Public Key Login Protocol", Work in Progress.
[PKLOGIN]David Kemp，“公钥登录协议”，正在进行中。
[R98] R. Rivest, "Can We Eliminate Revocation Lists?", to appear in the Proceedings of Financial Cryptography 1998, <http://theory.lcs.mit.edu/~rivest/revocation.ps>.
[R98]R.Rivest，“我们能消除撤销列表吗？”，发表在1998年《金融加密学报》上<http://theory.lcs.mit.edu/~rivest/revocation.ps>。
[RFC1114] Kent, S. and J. Linn, "Privacy Enhancement for Internet Electronic Mail: Part II -- Certificate-Based Key Management", RFC 1114, August 1989.
[RFC1114]Kent，S.和J.Linn，“互联网电子邮件的隐私增强：第二部分——基于证书的密钥管理”，RFC 11141989年8月。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321]Rivest，R.，“MD5消息摘要算法”，RFC13211992年4月。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, December 1996.
[RFC2045]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年12月。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, December 1996.
[RFC2046]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第二部分：媒体类型”，RFC 20461996年12月。
[RFC2047] K. Moore, "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, December 1996.
[RFC2047]K.Moore，“MIME（多用途互联网邮件扩展）第三部分：非ASCII文本的消息头扩展”，RFC 20471996年12月。
[RFC2065] Eastlake, D. and C. Kaufman, "Proposed Standard for DNS Security", RFC 2065, January 1997.
[RFC2065]Eastlake，D.和C.Kaufman，“DNS安全的拟议标准”，RFC 2065，1997年1月。
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104]Krawczyk，H.，Bellare，M.和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，1997年2月。
[SDSI] Ron Rivest and Butler Lampson, "SDSI - A Simple Distributed Security Infrastructure [SDSI]", <http://theory.lcs.mit.edu/~cis/sdsi.html>.
[SDSI]Ron Rivest和Butler Lampson，“SDSI-一种简单的分布式安全基础设施[SDSI]”<http://theory.lcs.mit.edu/~cis/sdsi.html>。
[SET] Secure Electronic Transactions -- a protocol designed by VISA, MasterCard and others, including a certificate structure covering all participants. See <http://www.visa.com/>.
[SET]安全电子交易——VISA、万事达卡和其他机构设计的协议，包括覆盖所有参与者的证书结构。看<http://www.visa.com/>.
[SEXP] Ron Rivest, code and description of S-expressions, <http://theory.lcs.mit.edu/~rivest/sexp.html>.
[SEXP]Ron Rivest，S表达式的代码和说明<http://theory.lcs.mit.edu/~rivest/sexp.html>。
[SRC-070] Abadi, Burrows, Lampson and Plotkin, "A Calculus for Access Control in Distributed Systems", DEC SRC-070, revised August 28, 1991.
[SRC-070]Abadi，Burrows，Lampson和Plotkin，“分布式系统中访问控制的演算”，DEC SRC-070，1991年8月28日修订。
[UPKI] C. Ellison, "The nature of a useable PKI", Computer Networks 31 (1999) pp. 823-830.
[UPKI]C.Ellison，“可用PKI的性质”，计算机网络31（1999）第823-830页。
[WEBSTER] "Webster's Ninth New Collegiate Dictionary", Merriam-Webster, Inc., 1991.
[韦伯斯特]《韦伯斯特第九部新学院词典》，韦伯斯特公司，1991年。
Acknowledgments
致谢
Several independent contributions, published elsewhere on the net or in print, worked in synergy with our effort. Especially important to our work were: [SDSI], [BFL] and [RFC2065]. The inspiration we received from the notion of CAPABILITY in its various forms (SDS-940, Kerberos, DEC DSSA, [SRC-070], KeyKOS [HARDY]) can not be over-rated.
一些独立的贡献，发表在网上或印刷品的其他地方，与我们的努力协同工作。对我们的工作特别重要的是：[SDSI]、[BFL]和[RFC2065]。我们从各种形式的能力概念（SDS-940、Kerberos、DEC DSSA、[SRC-070]、KeyKOS[HARDY]）中获得的灵感是不可低估的。
Significant contributions to this effort by the members of the SPKI mailing list and especially the following persons (listed in alphabetic order) are gratefully acknowledged: Steve Bellovin, Mark Feldman, John Gilmore, Phill Hallam-Baker, Bob Jueneman, David Kemp, Angelos D. Keromytis, Paul Lambert, Jon Lasser, Jeff Parrett, Bill Sommerfeld, Simon Spero.
感谢SPKI邮件列表的成员，特别是以下人员（按字母顺序排列）对这项工作做出的重大贡献：史蒂夫·贝洛文、马克·费尔德曼、约翰·吉尔摩、菲利普·哈拉姆·贝克、鲍勃·朱尼曼、大卫·肯普、安杰洛斯·D·科鲁米蒂斯、保罗·兰伯特、乔恩·拉瑟、杰夫·帕雷特、比尔·索末菲、，西蒙·斯佩罗。
Authors' Addresses
作者地址
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
Bill Frantz Electric Communities 10101 De Anza Blvd. Cupertino CA 95014
比尔·弗兰茨电气社区安扎大道10101号。Cupertino CA 95014
Phone: +1 408-342-9576
EMail: frantz@netcom.com
Phone: +1 408-342-9576
EMail: frantz@netcom.com
Butler Lampson Microsoft 180 Lake View Ave Cambridge MA 02138
Butler Lampson微软180 Lake View Ave Cambridge MA 02138
Phone: +1 617-547-9580 (voice + FAX)
EMail: blampson@microsoft.com
Phone: +1 617-547-9580 (voice + FAX)
EMail: blampson@microsoft.com
Ron Rivest Room 324, MIT Laboratory for Computer Science 545 Technology Square Cambridge MA 02139
麻省理工学院计算机科学实验室324室麻省剑桥545技术广场02139
Phone: +1-617-253-5880
Fax: +1-617-258-9738
EMail: rivest@theory.lcs.mit.edu
Web: http://theory.lcs.mit.edu/~rivest
Phone: +1-617-253-5880
Fax: +1-617-258-9738
EMail: rivest@theory.lcs.mit.edu
Web: http://theory.lcs.mit.edu/~rivest
Brian Thomas Southwestern Bell One Bell Center, Room 34G3 St. Louis MO 63101 USA
Brian Thomas西南贝尔一号贝尔中心，美国密苏里州圣路易斯市34G3室，邮编63101
Phone: +1 314-235-3141
Fax: +1 314-235-0162
EMail: bt0008@sbc.com
Phone: +1 314-235-3141
Fax: +1 314-235-0162
EMail: bt0008@sbc.com
Tatu Ylonen SSH Communications Security Ltd. Tekniikantie 12 FIN-02150 ESPOO Finland
Tatu Ylonen SSH通信安全有限公司Teknikantie 12 FIN-02150 ESPOO芬兰
EMail: ylo@ssh.fi
EMail: ylo@ssh.fi
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编辑功能的资金目前由互联网协会提供。