Network Working Group C. Francis
Request for Comments: 4476 Raytheon
Category: Standards Track D. Pinkas
Bull
May 2006
Network Working Group C. Francis
Request for Comments: 4476 Raytheon
Category: Standards Track D. Pinkas
Bull
May 2006
Attribute Certificate (AC) Policies Extension
属性证书（AC）策略扩展
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document describes one certificate extension that explicitly states the Attribute Certificate Policies (ACPs) that apply to a given Attribute Certificate (AC). The goal of this document is to allow relying parties to perform an additional test when validating an AC, i.e., to assess whether a given AC carrying some attributes can be accepted on the basis of references to one or more specific ACPs.
本文档描述了一个证书扩展，它明确说明了应用于给定属性证书（AC）的属性证书策略（ACP）。本文件的目的是允许依赖方在验证AC时执行附加测试，即，根据对一个或多个特定ACP的引用，评估是否可以接受具有某些属性的给定AC。
When issuing a Public Key Certificate (PKC), a Certificate Authority (CA) can perform various levels of verification with regard to the subject identity (see [RFC3280]). A CA makes its verification procedures, as well as other operational rules it abides by, "visible" through a certificate policy, which may be referenced by a certificate policies extension in the PKC.
颁发公钥证书（PKC）时，证书颁发机构（CA）可以对主体身份执行不同级别的验证（请参见[RFC3280]）。CA通过证书策略使其验证过程以及遵守的其他操作规则“可见”，PKC中的证书策略扩展可以引用该策略。
The purpose of this document is to define an Attribute Certificate (AC) policies extension able to explicitly state the AC policies that apply to a given AC, but not the AC policies themselves. Attribute Certificates are defined in [RFC3281].
本文档的目的是定义一个属性证书（AC）策略扩展，该扩展能够显式说明应用于给定AC的AC策略，但不能说明AC策略本身。属性证书在[RFC3281]中定义。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
An Attribute Certificate Policy is a named set of rules that indicates the applicability of an AC to a particular community and/or class of applications with common security requirements. It defines rules for the generation, issuance, and revocation of ACs. It may also include additional rules for attributes registration.
属性证书策略是一组命名规则，指示AC对具有通用安全要求的特定社区和/或应用程序类别的适用性。它定义了生成、发布和撤销ACs的规则。它还可能包括属性注册的附加规则。
Thus, note that an Attribute Authority (AA) does not necessarily support one single ACP. However, for each AC that is delivered, the AA SHALL make sure that the policy applies to all the attributes that are contained in it.
因此，请注意，属性权限（AA）不一定支持单个ACP。但是，对于交付的每个AC，AA应确保该政策适用于其中包含的所有属性。
An ACP may be used by an AC user to decide whether or not to trust the attributes contained in an AC for a particular purpose.
AC用户可以使用ACP来决定是否出于特定目的信任AC中包含的属性。
When an AC contains an AC policies extension, the extension MAY, at the option of the AA, be either critical or non-critical.
当AC包含AC策略扩展时，AA可选择该扩展为关键扩展或非关键扩展。
The AC Policies extension MAY be included in an AC. Like all X.509 certificate extensions [X.509], the AC policies extension is defined using ASN.1 [ASN1]. See Appendix A.
AC策略扩展可以包含在AC中。与所有X.509证书扩展[X.509]一样，AC策略扩展使用ASN.1[ASN1]定义。见附录A。
The definitions are presented in the 1988 Abstract Syntax Notation One (ASN.1) rather than the 1997 ASN.1 syntax used in the most recent ISO/IEC/ITU-T standards.
定义在1988年抽象语法符号1（ASN.1）中给出，而不是在最新ISO/IEC/ITU-T标准中使用的1997年ASN.1语法。
The AC policies extension is identified by id-pe-acPolicies.
AC策略扩展由id ACPE ACPOLICES标识。
id-pe-acPolicies OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) id-pkix(7) id-pe(1) 15 }
id-pe-acPolicies OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) id-pkix(7) id-pe(1) 15 }
The AC policies extension includes a list of AC policies recognized by the AA that apply to the attributes included in the AC.
AC策略扩展包括AA识别的适用于AC中包含的属性的AC策略列表。
AC Policies may be defined by any organization with a need. Object identifiers used to identify AC Policies are assigned in accordance with [X.660|ISO9834-1].
AC策略可由任何需要的组织定义。用于标识AC策略的对象标识符根据[X.660 | ISO9834-1]进行分配。
The AC policies extension in an AC indicates the AC policies for which the AC is valid.
AC中的AC策略扩展指示AC有效的AC策略。
An application that recognizes this extension and its content SHALL process the extension regardless of the value of the criticality flag.
识别该扩展及其内容的应用程序应处理该扩展，而不考虑关键性标志的值。
If the extension is both flagged non-critical and not recognized by the AC-using application, then the application MAY ignore it.
如果扩展被标记为非关键且AC使用应用程序无法识别，则应用程序可能会忽略它。
If the extension is marked critical or is recognized by the AC-using application, it indicates that the attributes contained in the attribute certificate SHALL only be used for the purpose, and in accordance with the rules associated with one of the indicated AC policies. If none of the ACP identifiers is adequate for the application, then the AC MUST be rejected.
如果扩展被标记为关键扩展或被AC使用应用程序识别，则表明属性证书中包含的属性只能用于此目的，并符合与所示AC策略之一相关的规则。如果没有一个ACP标识符适用于该应用，则必须拒绝该AC。
If the extension is marked critical or is recognized by the AC using application, the AC-using application MUST use the list of AC policies to determine whether it is appropriate to use the attributes contained in that AC for a particular transaction. When the appropriate policy is not found, the AC SHALL be rejected.
如果扩展被标记为关键扩展或被使用AC的应用程序识别，则使用AC的应用程序必须使用AC策略列表来确定是否适合将该AC中包含的属性用于特定事务。如果未找到适当的政策，则应拒绝AC。
The syntax for the AC Policy extension is:
AC策略扩展的语法为：
AcPoliciesSyntax ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation
AcPoliciesSyntax ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation
PolicyInformation ::= SEQUENCE {
policyIdentifier AcPolicyId,
policyQualifiers SEQUENCE SIZE (1..MAX) OF
PolicyQualifierInfo OPTIONAL}
PolicyInformation ::= SEQUENCE {
policyIdentifier AcPolicyId,
policyQualifiers SEQUENCE SIZE (1..MAX) OF
PolicyQualifierInfo OPTIONAL}
AcPolicyId ::= OBJECT IDENTIFIER
AcPolicyId ::= OBJECT IDENTIFIER
PolicyQualifierInfo ::= SEQUENCE {
policyQualifierId PolicyQualifierId,
qualifier ANY DEFINED BY policyQualifierId }
PolicyQualifierInfo ::= SEQUENCE {
policyQualifierId PolicyQualifierId,
qualifier ANY DEFINED BY policyQualifierId }
-- policyQualifierIds for Internet policy qualifiers
--Internet策略限定符的PolicyQualifierID
id-qt OBJECT IDENTIFIER ::= { id-pkix 2 }
id-qt-acps OBJECT IDENTIFIER ::= { id-qt 4 }
id-qt-acunotice OBJECT IDENTIFIER ::= { id-qt 5 }
id-qt OBJECT IDENTIFIER ::= { id-pkix 2 }
id-qt-acps OBJECT IDENTIFIER ::= { id-qt 4 }
id-qt-acunotice OBJECT IDENTIFIER ::= { id-qt 5 }
id-qt-acps OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) id-pkix(7) id-qt(2) 4 }
id-qt-acps OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) id-pkix(7) id-qt(2) 4 }
id-qt-acunotice OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) id-pkix(7) id-qt(2) 5 }
id-qt-acunotice OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) id-pkix(7) id-qt(2) 5 }
PolicyQualifierId ::=
OBJECT IDENTIFIER ( id-qt-acps | id-qt-acunotice )
PolicyQualifierId ::=
OBJECT IDENTIFIER ( id-qt-acps | id-qt-acunotice )
-- ACPS pointer qualifier
--指针限定符
ACPSuri ::= IA5String
-- ACP statement user notice qualifier
ACPSuri ::= IA5String
-- ACP statement user notice qualifier
ACUserNotice ::= UserNotice
-- UserNotice is defined in [RFC3280]
ACUserNotice ::= UserNotice
-- UserNotice is defined in [RFC3280]
To promote interoperability, this document RECOMMENDS that policy information terms consist of only an object identifier (OID). When more than one policy is used, the policy requirements have to be non-conflicting, e.g., one policy may refine the general requirements mandated by another policy.
为了促进互操作性，本文档建议策略信息术语仅由对象标识符（OID）组成。当使用多个策略时，策略要求必须是非冲突的，例如，一个策略可能会细化另一个策略强制执行的一般要求。
The extension defined in this specification supports two policy qualifier types for use by ACP writers and AAs. The qualifier types are the ACPS Pointer and the AC User.
本规范中定义的扩展支持两种策略限定符类型，供ACP编写器和AAs使用。限定符类型是ACPS指针和AC用户。
The ACPS Pointer qualifier contains a pointer to an Attribute Certification Practice Statement (ACPS) published by the AA. The pointer is in the form of a URI. Processing requirements for this qualifier are a local matter.
ACPS指针限定符包含指向AA发布的属性认证实践语句（ACPS）的指针。指针的形式为URI。此限定符的处理要求是本地事务。
The AC User Notice is intended for display to a relying party when an attribute certificate is used. The application software SHOULD display the AC User Notice of the AC. The AC User Notice is defined in [RFC3280]. It has two optional fields: the noticeRef field and the explicitText field.
AC用户通知旨在在使用属性证书时向依赖方显示。应用软件应显示空调的空调用户通知。空调用户通知在[RFC3280]中定义。它有两个可选字段：noticeRef字段和explicitText字段。
The noticeRef field, if used, names an organization and identifies, by number, a particular textual statement prepared by that organization. For example, it might identify the organization's name and notice number 1. In a typical implementation, the application software will have a notice file containing the current set of notices for the AA; the application will extract the notice text from the file and display it. Messages MAY be multilingual, allowing the software to select the particular language message for its own environment.
noticeRef字段（如果使用）命名一个组织，并通过编号标识该组织准备的特定文本声明。例如，它可能标识组织的名称和通知编号1。在典型的实现中，应用软件将有一个通知文件，其中包含AA的当前通知集；应用程序将从文件中提取通知文本并显示它。消息可以是多语言的，允许软件为自己的环境选择特定的语言消息。
An explicitText field includes the textual statement directly in the certificate. The explicitText field is a string with a maximum size of 200 characters.
explicitText字段直接在证书中包含文本语句。explicitText字段是最大大小为200个字符的字符串。
If both the noticeRef and explicitText options are included in the one qualifier, and if the application software can locate the notice text indicated by the noticeRef option, then that text SHOULD be displayed; otherwise, the explicitText string SHOULD be displayed.
如果noticeRef和explicitText选项都包含在一个限定符中，并且如果应用软件可以找到noticeRef选项指示的通知文本，则应显示该文本；否则，应显示explicitText字符串。
The scope of this document is not the definition of the detailed content of ACPs themselves; therefore, specific policies are not defined in this document.
本文件的范围不是ACP本身详细内容的定义；因此，本文件未定义具体政策。
The ACP defined in this document applies for all the attributes that are included in one AC. AAs SHALL ensure that the ACP applies to all the attributes that are included in the ACs they issue.
本文件中定义的ACP适用于一个AC中包含的所有属性。AAs应确保ACP适用于其发布的ACs中包含的所有属性。
Attributes may be dynamically grouped in several ACs. It should be observed that since an AC may be issued under more than one ACP, the attributes included in a given AC MUST be compliant with all the ACPs from that AC.
属性可以在多个AC中动态分组。应注意的是，由于一个AC可能在多个ACP下发布，因此给定AC中包含的属性必须符合该AC中的所有ACP。
When verifying an AC, a relying party MUST determine that the AC was issued by a trusted AA and then that it has the appropriate policy.
验证AC时，依赖方必须确定AC是由受信任的AA颁发的，然后确定其具有适当的策略。
Failure of AAs to protect their private keys will permit an attacker to masquerade as them, potentially generating false ACs or revocation status. Existence of bogus ACs and revocation status will undermine confidence in the system. If the compromise is detected, then the certificate of the AA MUST be revoked.
AAs未能保护其私钥将允许攻击者伪装成它们，从而可能产生虚假的ACs或吊销状态。虚假ACs和吊销状态的存在将破坏对系统的信心。如果检测到泄露，则必须撤销AA的证书。
Rebuilding after such a compromise will be problematic, so AAs are advised to implement a combination of strong technical measures (e.g., tamper-resistant cryptographic modules) and appropriate management procedures (e.g., separation of duties) to avoid such an incident.
在这种妥协后重建将是有问题的，因此建议AAs实施强有力的技术措施（例如，防篡改加密模块）和适当的管理程序（例如，职责分离）相结合，以避免此类事件。
Loss of an AA's private signing key may also be problematic. The AA would not be able to produce revocation status or perform AC renewal (i.e., the issue of a new AC with the same set of attributes with the same values, for the same holder, from the same AA but with a different validity period). AC issuers are advised to maintain secure backup for signing keys. The security of the key backup procedures is a critical factor in avoiding key compromise.
AA的私人签名密钥丢失也可能有问题。机管局将无法产生撤销状态或执行AC更新（即，对于同一持有人，从同一机管局发出具有相同属性集且具有相同值的新AC，但有效期不同）。建议AC发行人维护签名密钥的安全备份。密钥备份过程的安全性是避免密钥泄露的关键因素。
The availability and freshness of revocation status will affect the degree of assurance that should be placed in a long-lived AC. While long-lived ACs expire naturally, events may occur during an AC's natural lifetime that negate the binding between the AC holder and the attributes. If revocation status is untimely or unavailable, the assurance associated with the binding is clearly reduced.
吊销状态的可用性和新鲜度将影响应放置在长寿命AC中的保证程度。虽然长寿命AC自然过期，但在AC的自然生存期内可能会发生否定AC持有者和属性之间绑定的事件。如果撤销状态不及时或不可用，则与绑定相关的保证将明显减少。
The binding between an AC holder and attributes cannot be stronger than the cryptographic module implementation and algorithms used to generate the signature. Short key lengths or weak hash algorithms will limit the utility of an AC. AAs are encouraged to note advances in cryptology so they can employ strong cryptographic techniques.
AC持有者和属性之间的绑定不能强于用于生成签名的加密模块实现和算法。短密钥长度或弱散列算法将限制AC的实用性。鼓励AAs注意密码学的进步，以便他们可以使用强加密技术。
If an AC is tied to the holder's PKC using the baseCertificateID component of the Holder field and the PKI in use includes a rogue CA with the same issuer name specified in the baseCertificateID component, this rogue CA could issue a PKC to a malicious party, using the same issuer name and serial number as the proper holder's PKC. Then the malicious party could use this PKC in conjunction with the AC. This scenario SHOULD be avoided by properly managing and configuring the PKI so that there cannot be two CAs with the same name. Another alternative is to tie ACs to PKCs using the publicKeyCert type in the ObjectDigestInfo field. Failing this, AC verifiers have to establish (using other means) that the potential collisions cannot actually occur; for example, the Certificate Policy Statements (CPSs) of the CAs involved may make it clear that no such name collisions can occur.
如果AC使用持有者字段的baseCertificateID组件绑定到持有者的PKC，并且使用中的PKI包括具有baseCertificateID组件中指定的相同颁发者名称的流氓CA，则此流氓CA可以使用与适当持有者PKC相同的颁发者名称和序列号向恶意方颁发PKC。然后，恶意方可以将此PKC与AC一起使用。应通过正确管理和配置PKI来避免这种情况，以便不会有两个具有相同名称的CA。另一种选择是使用ObjectDigestInfo字段中的publicKeyCert类型将ACs与PKCs绑定。如果不能做到这一点，AC验证器必须（使用其他方法）确定潜在碰撞实际上不会发生；例如，所涉及的CA的证书策略声明（CPS）可能明确表明不会发生此类名称冲突。
Implementers MUST ensure that following validation of an AC, only attributes that the issuer is trusted to issue are used in authorization decisions. Other attributes, which MAY be present, MUST be ignored. AC verifiers SHALL support means of being provided with this information. The AA controls PKC extension (see [RFC3281]) is one possibility, but it is optional to implement. Configuration information is a likely alternative means, while out-of-band means is another. This becomes very important if an AC verification application trusts more than one AC issuer.
实施者必须确保在AC验证之后，授权决策中仅使用发卡机构受信任可以发布的属性。必须忽略可能存在的其他属性。交流验证者应支持提供该信息的方式。AA控制PKC扩展（请参见[RFC3281]）是一种可能性，但它是可选的。配置信息是一种可能的替代方式，而带外方式是另一种。如果AC验证应用程序信任多个AC颁发者，这一点就变得非常重要。
The AC policies extension is identified by an object identifier (OID). The OID for the AC policies extension defined in this document was assigned from an arc delegated by the IANA to the PKIX Working Group.
AC策略扩展由对象标识符（OID）标识。本文件中定义的AC策略扩展的OID由IANA委托给PKIX工作组的arc分配。
No further action by the IANA is necessary for this document.
本文件无需IANA采取进一步行动。
[X.660|ISO9834-1] ITU-T Recommendation X.660 (1992) | ISO/IEC 9834-1: 1993, Information technology - Open Systems Interconnection Procedures for the operation of OSI Registration Authorities: General procedures.
[X.660 | ISO9834-1]ITU-T建议X.660（1992）| ISO/IEC 9834-1:1993，信息技术-开放系统互连（OSI）注册机构运行的开放系统互连程序：一般程序。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
2002年4月，福特公司发布了《公共基础设施许可证》和《公共基础设施许可证撤销许可证》（RFC.3280），并于2002年4月发布。
[RFC3281] Farrell, S. and R. Housley, "An Internet Attribute Certificate Profile for Authorization", RFC 3281, April 2002.
[RFC3281]Farrell，S.和R.Housley，“用于授权的Internet属性证书配置文件”，RFC 3281，2002年4月。
[ASN1] X.680 - X.693 | ISO/IEC 8824: 1-4 Abstract Syntax Notation One (ASN.1).
[ASN1]X.680-X.693 | ISO/IEC 8824:1-4抽象语法符号1（ASN.1）。
[X.509] ITU-T Recommendation X.509 (2000): Information Technology Open Systems Interconnections - The Directory: Public-key and Attribute Frameworks, March 2000.
[X.509]ITU-T建议X.509（2000）：信息技术开放系统互连——目录：公钥和属性框架，2000年3月。
This appendix is normative.
本附录为规范性附录。
ASN.1 Module
ASN.1模块
AcPolicies { iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-ac-policies(26) }
AcPolicies { iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-ac-policies(26) }
DEFINITIONS IMPLICIT TAGS ::=
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
开始
-- EXPORTS ALL --
--全部出口--
IMPORTS
进口
-- Imports from RFC 3280 [RFC3280], Appendix A
--从RFC 3280[RFC3280]进口，附录A
UserNotice
FROM PKIX1Implicit88 { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) 19 }
UserNotice
FROM PKIX1Implicit88 { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) 19 }
id-pkix, id-pe
FROM PKIX1Explicit88 { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) 18 };
id-pkix, id-pe
FROM PKIX1Explicit88 { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) 18 };
-- Locally defined OIDs
--局部定义的OID
-- policyQualifierIds for Internet policy qualifiers
--Internet策略限定符的PolicyQualifierID
id-qt OBJECT IDENTIFIER ::= { id-pkix 2 }
id-qt-acps OBJECT IDENTIFIER ::= { id-qt 4 }
id-qt-acunotice OBJECT IDENTIFIER ::= { id-qt 5 }
id-qt OBJECT IDENTIFIER ::= { id-pkix 2 }
id-qt-acps OBJECT IDENTIFIER ::= { id-qt 4 }
id-qt-acunotice OBJECT IDENTIFIER ::= { id-qt 5 }
-- Attributes
--属性
id-pe-acPolicies OBJECT IDENTIFIER ::= { id-pe 15 }
id-pe-acPolicies OBJECT IDENTIFIER ::= { id-pe 15 }
AcPoliciesSyntax ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation
AcPoliciesSyntax ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation
PolicyInformation ::= SEQUENCE {
policyIdentifier AcPolicyId,
policyQualifiers SEQUENCE SIZE (1..MAX) OF
PolicyQualifierInfo OPTIONAL }
PolicyInformation ::= SEQUENCE {
policyIdentifier AcPolicyId,
policyQualifiers SEQUENCE SIZE (1..MAX) OF
PolicyQualifierInfo OPTIONAL }
AcPolicyId ::= OBJECT IDENTIFIER
AcPolicyId ::= OBJECT IDENTIFIER
PolicyQualifierInfo ::= SEQUENCE {
policyQualifierId PolicyQualifierId,
qualifier ANY DEFINED BY policyQualifierId }
PolicyQualifierInfo ::= SEQUENCE {
policyQualifierId PolicyQualifierId,
qualifier ANY DEFINED BY policyQualifierId }
PolicyQualifierId ::=
OBJECT IDENTIFIER ( id-qt-acps | id-qt-acunotice )
-- ACPS pointer qualifier
PolicyQualifierId ::=
OBJECT IDENTIFIER ( id-qt-acps | id-qt-acunotice )
-- ACPS pointer qualifier
ACPSuri ::= IA5String
-- ACP statement user notice qualifier
ACPSuri ::= IA5String
-- ACP statement user notice qualifier
ACUserNotice ::= UserNotice
-- UserNotice is defined in [RFC3280]
ACUserNotice ::= UserNotice
-- UserNotice is defined in [RFC3280]
END
终止
Authors' Addresses
作者地址
Christopher S. Francis Raytheon 1501 72nd Street North, MS 25 St. Petersburg, Florida 33764
克里斯托弗·S·弗朗西斯·雷声公司佛罗里达州圣彼得堡25号72街北1501号，邮编33764
EMail: Chris_S_Francis@Raytheon.com
EMail: Chris_S_Francis@Raytheon.com
Denis Pinkas Bull Rue Jean Jaures 78340 Les Clayes-sous-Bois FRANCE
Denis Pinkas Bull Rue Jean Jaures 78340 Les Clays sous Bois FRANCE
EMail: Denis.Pinkas@bull.net
EMail: Denis.Pinkas@bull.net
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。