Network Working Group S. Santesson
Request for Comments: 3709 Microsoft
Category: Standards Track R. Housley
Vigil Security
T. Freeman
Microsoft
February 2004
Network Working Group S. Santesson
Request for Comments: 3709 Microsoft
Category: Standards Track R. Housley
Vigil Security
T. Freeman
Microsoft
February 2004
Internet X.509 Public Key Infrastructure: Logotypes in X.509 Certificates
Internet X.509公钥基础设施：X.509证书中的标识类型
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 (2004). All Rights Reserved.
版权所有（C）互联网协会（2004年）。版权所有。
Abstract
摘要
This document specifies a certificate extension for including logotypes in public key certificates and attribute certificates.
本文档指定了一个证书扩展，用于在公钥证书和属性证书中包含标识类型。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Certificate-based Identification . . . . . . . . . . . . 3
1.2. Selection of Certificates. . . . . . . . . . . . . . . . 4
1.3. Combination of Verification Techniques . . . . . . . . . 5
1.4. Terminology. . . . . . . . . . . . . . . . . . . . . . . 6
2. Different types of logotypes in Certificates . . . . . . . . . 6
3. Logotype Data. . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Logotype Extension . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Extension Format . . . . . . . . . . . . . . . . . . . . 7
4.2. Other Logotypes. . . . . . . . . . . . . . . . . . . . . 11
5. Type of Certificates . . . . . . . . . . . . . . . . . . . . . 12
6. Use in Clients . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations. . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . 16
A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . . . . 17
B. Example Extension. . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Certificate-based Identification . . . . . . . . . . . . 3
1.2. Selection of Certificates. . . . . . . . . . . . . . . . 4
1.3. Combination of Verification Techniques . . . . . . . . . 5
1.4. Terminology. . . . . . . . . . . . . . . . . . . . . . . 6
2. Different types of logotypes in Certificates . . . . . . . . . 6
3. Logotype Data. . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Logotype Extension . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Extension Format . . . . . . . . . . . . . . . . . . . . 7
4.2. Other Logotypes. . . . . . . . . . . . . . . . . . . . . 11
5. Type of Certificates . . . . . . . . . . . . . . . . . . . . . 12
6. Use in Clients . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations. . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . 16
A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . . . . 17
B. Example Extension. . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 21
This specification supplements RFC 3280 [PKIX-1], which profiles X.509 [X.509] certificates and certificate revocation lists (CRLs) for use in the Internet.
本规范是对RFC 3280[PKIX-1]的补充，RFC 3280[PKIX-1]配置了用于Internet的X.509[X.509]证书和证书吊销列表（CRL）。
The basic function of a certificate is to bind a public key to the identity of an entity (the subject). From a strictly technical viewpoint, this goal could be achieved by signing the identity of the subject together with its public key. However, the art of Public-Key Infrastructure (PKI) has developed certificates far beyond this functionality in order to meet the needs of modern global networks and heterogeneous IT structures.
证书的基本功能是将公钥绑定到实体（主体）的标识。从严格的技术角度来看，这一目标可以通过签署主体的身份及其公钥来实现。然而，公钥基础设施（PKI）技术已经开发出远远超出此功能的证书，以满足现代全球网络和异构IT结构的需要。
Certificate users must be able to determine certificate policies, appropriate key usage, assurance level, and name form constraints. Before a relying party can make an informed decision whether a particular certificate is trustworthy and relevant for its intended usage, a certificate may be examined from several different perspectives.
证书用户必须能够确定证书策略、适当的密钥使用、保证级别和名称表单约束。在依赖方能够在知情的情况下决定某一特定证书是否可信并与其预期用途相关之前，可以从几个不同的角度对证书进行检查。
Systematic processing is necessary to determine whether a particular certificate meets the predefined prerequisites for an intended usage. Much of the information contained in certificates is appropriate and effective for machine processing; however, this information is not suitable for a corresponding human trust and recognition process.
有必要进行系统处理，以确定特定证书是否满足预期用途的预定义先决条件。证书中包含的大部分信息对于机器处理是适当和有效的；然而，这些信息并不适用于相应的人类信任和识别过程。
Humans prefer to structure information into categories and symbols. Most humans associate complex structures of reality with easily recognizable logotypes and marks. Humans tend to trust things that they recognize from previous experiences. Humans may examine information to confirm their initial reaction. Very few consumers actually read all terms and conditions they agree to in accepting a service, rather they commonly act on trust derived from previous experience and recognition.
人类更喜欢将信息组织成类别和符号。大多数人将现实的复杂结构与易于识别的标识和标记联系起来。人类倾向于相信他们从以前的经历中认识到的东西。人类可能会检查信息以确认他们最初的反应。很少有消费者真正阅读了他们在接受服务时同意的所有条款和条件，而他们通常是根据以前的经验和认可所产生的信任来行事。
A big part of this process is branding. Service providers and product vendors invest a lot of money and resources into creating a strong relation between positive user experiences and easily recognizable trademarks, servicemarks, and logotypes.
这一过程的很大一部分是品牌化。服务提供商和产品供应商投入大量资金和资源，在积极的用户体验和易于识别的商标、服务标志和标识之间建立牢固的关系。
Branding is also pervasive in identification instruments, including identification cards, passports, driver's licenses, credit cards, gasoline cards, and loyalty cards. Identification instruments are intended to identify the holder as a particular person or as a member of the community. The community may represent the subscribers of a service or any other group. Identification instruments, in physical form, commonly use logotypes and symbols, solely to enhance human recognition and trust in the identification instrument itself. They may also include a registered trademark to allow legal recourse for unauthorized duplication.
品牌在身份识别工具中也很普遍，包括身份证、护照、驾照、信用卡、汽油卡和忠诚卡。身份识别工具旨在将持有人识别为特定人员或社区成员。社区可以代表服务或任何其他组的订户。实物形式的身份识别工具通常使用标识和符号，仅用于增强人类对身份识别工具本身的识别和信任。它们还可能包括注册商标，以便对未经授权的复制进行法律追索。
Since certificates play an equivalent role in electronic exchanges, we examine the inclusion of logotypes in certificates. We consider certificate-based identification and certificate selection.
由于证书在电子交换中扮演着同等的角色，我们研究了证书中包含的标识类型。我们考虑基于证书的识别和证书选择。
The need for human recognition depends on the manner in which certificates are used and whether certificates need to be visible to human users. If certificates are to be used in open environments and in applications that bring the user in conscious contact with the result of a certificate-based identification process, then human recognition is highly relevant, and may be a necessity.
人类识别的需要取决于证书的使用方式以及证书是否需要对人类用户可见。如果证书将用于开放环境和应用程序中，使用户有意识地接触基于证书的识别过程的结果，那么人类识别是高度相关的，并且可能是必要的。
Examples of such applications include:
这类应用的例子包括：
- Web server identification where a user identifies the owner of the web site.
- 用户标识网站所有者的Web服务器标识。
- Peer e-mail exchange in B2B, B2C, and private communications.
- B2B、B2C和私人通信中的对等电子邮件交换。
- Exchange of medical records, and system for medical prescriptions.
- 医疗记录交换，以及医疗处方系统。
- Unstructured e-business applications (i.e., non-EDI applications).
- 非结构化电子商务应用程序（即非EDI应用程序）。
- Wireless client authenticating to a service provider.
- 向服务提供商进行无线客户端身份验证。
Most applications provide the human user with an opportunity to view the results of a successful certificate-based identification process. When the user takes the steps necessary to view these results, the user is presented with a view of a certificate. This solution has two major problems. First, the function to view a certificate is often rather hard to find for a non-technical user. Second, the presentation of the certificate is too technical and is not user friendly. It contains no graphic symbols or logotypes to enhance human recognition.
大多数应用程序为人类用户提供了一个查看基于证书的成功识别过程结果的机会。当用户采取查看这些结果所需的步骤时，将向用户显示证书的视图。这个解决方案有两个主要问题。首先，对于非技术用户来说，查看证书的功能通常很难找到。第二，证书的呈现过于技术化，不便于用户使用。它不包含图形符号或标识以增强人类识别。
Many investigations have shown that users of today's applications do not take the steps necessary to view certificates. This could be due to poor user interfaces. Further, many applications are structured to hide certificates from users. The application designers do not want to expose certificates to users at all.
许多调查表明，当今应用程序的用户没有采取查看证书所需的步骤。这可能是由于糟糕的用户界面造成的。此外，许多应用程序的结构都是对用户隐藏证书。应用程序设计者根本不想向用户公开证书。
One situation where software applications must expose human users to certificates is when the user must select a single certificate from a portfolio of certificates. In some cases, the software application can use information within the certificates to filter the list for suitability; however, the user must be queried if more than one certificate is suitable. The human user must select one of them.
软件应用程序必须向人类用户公开证书的一种情况是，用户必须从证书组合中选择单个证书。在某些情况下，软件应用程序可以使用证书中的信息来过滤列表的适用性；但是，必须询问用户是否有多个证书适用。人工用户必须选择其中一个。
This situation is comparable to a person selecting a suitable plastic card from his wallet. In this situation, substantial assistance is provided by card color, location, and branding.
这种情况相当于一个人从钱包中选择合适的塑料卡。在这种情况下，卡的颜色、位置和品牌可以提供实质性的帮助。
In order to provide similar support for certificate selection, the users need tools to easily recognize and distinguish certificates. Introduction of logotypes into certificates provides the necessary graphic.
为了为证书选择提供类似的支持，用户需要能够轻松识别和区分证书的工具。在证书中引入标识提供了必要的图形。
The use of logotypes will, in many cases, affect the users decision to trust and use a certificate. It is therefore important that there be a distinct and clear architectural and functional distinction between the processes and objectives of the automated certificate verification and human recognition.
在许多情况下，标识的使用会影响用户信任和使用证书的决定。因此，重要的是，在自动证书验证和人工识别的过程和目标之间有一个明确的体系结构和功能区别。
Since logotypes are only aimed for human interpretation and contain data that is inappropriate for computer based verification schemes, the logotype extension MUST NOT be an active component in automated certification path validation.
由于标识仅用于人工解释，并且包含不适用于基于计算机的验证方案的数据，因此标识扩展不得是自动认证路径验证中的活动组件。
Automated certification path verification determines whether the end-entity certificate can be verified according to defined policy. The algorithm for this verification is specified in RFC 3280 [PKIX-1].
自动证书路径验证确定是否可以根据定义的策略验证最终实体证书。RFC 3280[PKIX-1]中规定了此验证的算法。
The automated processing provides assurance that the certificate is valid. It does not indicate whether the subject is entitled to any particular information, or whether the subject ought to be trusted to perform a particular service. These are access control decisions. Automatic processing will make some access control decisions, but others, depending on the application context, involve the human user.
自动处理提供了证书有效性的保证。它没有指明受试者是否有权获得任何特定信息，或者是否应该信任受试者执行特定服务。这些是访问控制决策。自动处理将做出一些访问控制决策，但其他决策则取决于应用程序上下文，涉及到人类用户。
In some situations, where automated procedures have failed to establish the suitability of the certificate to the task, the human user is the final arbitrator of the post certificate verification access control decisions. In the end, the human will decide whether or not to accept an executable email attachment, to release personal information, or follow the instructions displayed by a web browser. This decision will often be based on recognition and previous experience.
在某些情况下，当自动程序无法确定证书是否适合任务时，人工用户是证书验证后访问控制决策的最终仲裁人。最后，人类将决定是否接受可执行的电子邮件附件、是否发布个人信息或是否遵循web浏览器显示的指示。这一决定通常基于认可和以前的经验。
The distinction between systematic processing and human processing is rather straightforward. They can be complementary. While the systematic process is focused on certification path construction and verification, the human acceptance process is focused on recognition and related previous experience.
系统处理和人工处理之间的区别相当简单。它们可以是互补的。系统过程侧重于认证路径的构建和验证，而人的接受过程侧重于认可和相关的以往经验。
There are some situations where systematic processing and human processing interfere with each other. These issues are discussed in the Security Considerations section.
有些情况下，系统处理和人工处理相互干扰。这些问题将在“安全注意事项”一节中讨论。
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 BCP 14, RFC 2119 [STDWORDS].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[STDWORDS]中的描述进行解释。
This specification defines the inclusion of three standard logotype types.
本规范定义了三种标准标识类型。
1) Community logotype 2) Issuer organization logotype 3) Subject organization logotype
1) 社区标识2）发行人组织标识3）主体组织标识
The community logotype - is the general mark for a community. It identifies a service concept for entity identification and certificate issuance. Many issuers may use a community logotype to co-brand with a global community in order to gain global recognition of its local service provision. This type of community branding is very common in the credit card business, where local independent card issuers include a globally recognized brand (such as VISA and MasterCard).
社区标识-是社区的通用标志。它确定了实体标识和证书颁发的服务概念。许多发行人可能使用社区标识与全球社区联合品牌，以获得其本地服务提供的全球认可。这种类型的社区品牌在信用卡业务中非常常见，当地独立发卡机构包括全球认可的品牌（如VISA和MasterCard）。
Issuer organization logotype - is a logotype representing the organization identified as part of the issuer name in the certificate.
发卡机构组织标识-是表示证书中作为发卡机构名称一部分标识的组织的标识。
Subject organization logotype - is a logotype representing the organization identified in the subject name in the certificate.
主体组织标识-表示证书主体名称中标识的组织的标识。
In addition to the standard logotype types, this specification accommodates inclusion of other logotype types where each class of logotype is defined by an object identifier. The object identifier can be either locally defined or an identifier defined in section 4.2 of this document.
除标准标识类型外，本规范还包括其他标识类型，其中每类标识由对象标识符定义。对象标识符可以是本地定义的，也可以是本文件第4.2节中定义的标识符。
This specification defines two types of logotype data: image data and audio data. Implementations MUST support image data; however, support for audio data is OPTIONAL.
本规范定义了两种类型的标识数据：图像数据和音频数据。实现必须支持图像数据；但是，对音频数据的支持是可选的。
There is no need to significantly increase the size of the certificate by including image and audio data of logotypes. Rather, a URI identifying the location to the logotype data and a one-way hash of the referenced data is included in the certificate.
不需要通过包含标识的图像和音频数据来显著增加证书的大小。相反，证书中包括标识到标识数据的位置的URI和引用数据的单向散列。
Several image files, representing the same image in different formats, sizes, and color palates, may represent each logotype image. At least one of the image files representing a logotype SHOULD contain an image within the size range of 60 pixels wide by 45 pixels high, and 200 pixels wide by 150 pixels high.
多个图像文件以不同的格式、大小和颜色表示同一图像，可以表示每个标识图像。表示标识的图像文件中的至少一个应包含尺寸范围为60像素宽45像素高和200像素宽150像素高的图像。
Several audio files may further represent the same audio sequence in different formats and resolutions. At least one of the audio files representing a logotype SHOULD have a play time between 1 and 30 seconds.
多个音频文件还可以以不同的格式和分辨率表示相同的音频序列。至少一个代表标识的音频文件的播放时间应在1到30秒之间。
If a logotype of a certain type (as defined in section 2) is represented by more than one image file, then the image files MUST contain variants of roughly the same image. Likewise, if a logotype of a certain type is represented by more than one audio file, then the audio files MUST contain variants of the same audio information. A spoken message in different languages is considered a variation of the same audio information. Compliant applications MUST NOT display more than one of the images and MUST NOT play more than one of the audio sequences for any logotype type at the same time.
如果某一类型的标识（如第2节所定义）由多个图像文件表示，则图像文件必须包含大致相同图像的变体。同样，如果某一类型的标识由多个音频文件表示，则音频文件必须包含相同音频信息的变体。不同语言的语音信息被视为相同音频信息的变体。兼容应用程序不得显示多个图像，且不得同时播放任何标识类型的多个音频序列。
A client MAY simultaneously display multiple logotypes of different logotype types. For example, it may display one subject organization logotype while also displaying a community logotype, but it MUST NOT display multiple image variants of the same community logotype.
客户端可以同时显示不同标识类型的多个标识。例如，它可以显示一个主题组织标识，同时也显示社区标识，但不能显示同一社区标识的多个图像变体。
Each logotype present in a certificate MUST be represented by at least one image data file.
证书中的每个标识必须至少由一个图像数据文件表示。
Applications SHOULD enhance processing and off-line functionality by caching logotype data.
应用程序应该通过缓存标识数据来增强处理和离线功能。
This section specifies the syntax and semantics of the logotype extension.
本节指定标识扩展的语法和语义。
The logotype extension MAY be included in public key certificates [PKIX-1] or attribute certificates [PKIX-AC]. The logotype extension MUST be identified by the following object identifier:
标识扩展可以包含在公钥证书[PKIX-1]或属性证书[PKIX-AC]中。标识扩展必须由以下对象标识符标识：
id-pe-logotype OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-pe(1) 12 }
id-pe-logotype OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-pe(1) 12 }
This extension MUST NOT be marked critical.
此扩展不能标记为关键。
Logotype data may be referenced through either direct or indirect addressing. Clients MUST support both direct and indirect addressing. Certificate issuing applications MUST support direct addressing, and certificate issuing applications SHOULD support indirect addressing.
标识数据可通过直接或间接寻址引用。客户机必须支持直接寻址和间接寻址。证书颁发应用程序必须支持直接寻址，证书颁发应用程序应支持间接寻址。
The direct addressing includes information about each logotype in the certificate, and URIs point to the image and audio data files. Direct addressing supports cases where just one or a few alternative images and audio files are referenced.
直接寻址包括有关证书中每个标识的信息，URI指向图像和音频数据文件。直接寻址支持仅引用一个或几个备选图像和音频文件的情况。
The indirect addressing includes one reference to an external hashed data structure that contains information on the type, content, and location of each image and audio file. Indirect addressing supports cases where each logotype is represented by many alternative audio or image files.
间接寻址包括一个对外部散列数据结构的引用，该结构包含关于每个图像和音频文件的类型、内容和位置的信息。间接寻址支持每个标识由许多可选音频或图像文件表示的情况。
Both direct and indirect addressing accommodate alternative URIs to obtain exactly the same item. This opportunity for replication is intended to improve availability. Therefore, if a client is unable to fetch the item from one URI, the client SHOULD try another URI in the sequence. All URIs MUST use either the HTTP scheme (http://...) or the FTP scheme (ftp://...) [URI]. At least one URI in each sequence MUST use the HTTP scheme. Clients MUST support retrieval of referenced LogoTypeData with HTTP/1.1 [HTTP/1.1]. Clients MAY support retrieval using FTP [FTP].
直接寻址和间接寻址都支持替代URI以获得完全相同的项。此复制机会旨在提高可用性。因此，如果客户端无法从一个URI获取项目，则客户端应尝试序列中的另一个URI。所有URI都必须使用HTTP方案(http://...)还是FTP方案(ftp://...)[URI]。每个序列中必须至少有一个URI使用HTTP方案。客户端必须支持使用HTTP/1.1[HTTP/1.1]检索引用的LogoTypeData。客户端可能支持使用FTP[FTP]进行检索。
The logotype extension MUST have the following syntax:
标识扩展必须具有以下语法：
LogotypeExtn ::= SEQUENCE {
communityLogos [0] EXPLICIT SEQUENCE OF LogotypeInfo OPTIONAL,
issuerLogo [1] EXPLICIT LogotypeInfo OPTIONAL,
subjectLogo [2] EXPLICIT LogotypeInfo OPTIONAL,
otherLogos [3] EXPLICIT SEQUENCE OF OtherLogotypeInfo OPTIONAL }
LogotypeExtn ::= SEQUENCE {
communityLogos [0] EXPLICIT SEQUENCE OF LogotypeInfo OPTIONAL,
issuerLogo [1] EXPLICIT LogotypeInfo OPTIONAL,
subjectLogo [2] EXPLICIT LogotypeInfo OPTIONAL,
otherLogos [3] EXPLICIT SEQUENCE OF OtherLogotypeInfo OPTIONAL }
LogotypeInfo ::= CHOICE {
direct [0] LogotypeData,
indirect [1] LogotypeReference }
LogotypeInfo ::= CHOICE {
direct [0] LogotypeData,
indirect [1] LogotypeReference }
LogotypeData ::= SEQUENCE {
image SEQUENCE OF LogotypeImage OPTIONAL,
audio [1] SEQUENCE OF LogotypeAudio OPTIONAL }
LogotypeData ::= SEQUENCE {
image SEQUENCE OF LogotypeImage OPTIONAL,
audio [1] SEQUENCE OF LogotypeAudio OPTIONAL }
LogotypeImage ::= SEQUENCE {
imageDetails LogotypeDetails,
imageInfo LogotypeImageInfo OPTIONAL }
LogotypeImage ::= SEQUENCE {
imageDetails LogotypeDetails,
imageInfo LogotypeImageInfo OPTIONAL }
LogotypeAudio ::= SEQUENCE {
audioDetails LogotypeDetails,
audioInfo LogotypeAudioInfo OPTIONAL }
LogotypeAudio ::= SEQUENCE {
audioDetails LogotypeDetails,
audioInfo LogotypeAudioInfo OPTIONAL }
LogotypeDetails ::= SEQUENCE {
mediaType IA5String, -- MIME media type name and optional
-- parameters
logotypeHash SEQUENCE SIZE (1..MAX) OF HashAlgAndValue,
logotypeURI SEQUENCE SIZE (1..MAX) OF IA5String }
LogotypeDetails ::= SEQUENCE {
mediaType IA5String, -- MIME media type name and optional
-- parameters
logotypeHash SEQUENCE SIZE (1..MAX) OF HashAlgAndValue,
logotypeURI SEQUENCE SIZE (1..MAX) OF IA5String }
LogotypeImageInfo ::= SEQUENCE {
type [0] LogotypeImageType DEFAULT color,
fileSize INTEGER, -- In octets
xSize INTEGER, -- Horizontal size in pixels
ySize INTEGER, -- Vertical size in pixels
resolution LogotypeImageResolution OPTIONAL,
language [4] IA5String OPTIONAL } -- RFC 3066 Language Tag
LogotypeImageInfo ::= SEQUENCE {
type [0] LogotypeImageType DEFAULT color,
fileSize INTEGER, -- In octets
xSize INTEGER, -- Horizontal size in pixels
ySize INTEGER, -- Vertical size in pixels
resolution LogotypeImageResolution OPTIONAL,
language [4] IA5String OPTIONAL } -- RFC 3066 Language Tag
LogotypeImageType ::= INTEGER { grayScale(0), color(1) }
LogotypeImageType ::= INTEGER { grayScale(0), color(1) }
LogotypeImageResolution ::= CHOICE {
numBits [1] INTEGER, -- Resolution in bits
tableSize [2] INTEGER } -- Number of colors or grey tones
LogotypeImageResolution ::= CHOICE {
numBits [1] INTEGER, -- Resolution in bits
tableSize [2] INTEGER } -- Number of colors or grey tones
LogotypeAudioInfo ::= SEQUENCE {
fileSize INTEGER, -- In octets
playTime INTEGER, -- In milliseconds
channels INTEGER, -- 1=mono, 2=stereo, 4=quad
sampleRate [3] INTEGER OPTIONAL, -- Samples per second
language [4] IA5String OPTIONAL } -- RFC 3066 Language Tag
LogotypeAudioInfo ::= SEQUENCE {
fileSize INTEGER, -- In octets
playTime INTEGER, -- In milliseconds
channels INTEGER, -- 1=mono, 2=stereo, 4=quad
sampleRate [3] INTEGER OPTIONAL, -- Samples per second
language [4] IA5String OPTIONAL } -- RFC 3066 Language Tag
OtherLogotypeInfo ::= SEQUENCE {
logotypeType OBJECT IDENTIFIER,
info LogotypeInfo }
OtherLogotypeInfo ::= SEQUENCE {
logotypeType OBJECT IDENTIFIER,
info LogotypeInfo }
LogotypeReference ::= SEQUENCE {
refStructHash SEQUENCE SIZE (1..MAX) OF HashAlgAndValue,
refStructURI SEQUENCE SIZE (1..MAX) OF IA5String }
-- Places to get the same "LTD" file
LogotypeReference ::= SEQUENCE {
refStructHash SEQUENCE SIZE (1..MAX) OF HashAlgAndValue,
refStructURI SEQUENCE SIZE (1..MAX) OF IA5String }
-- Places to get the same "LTD" file
HashAlgAndValue ::= SEQUENCE {
hashAlg AlgorithmIdentifier,
hashValue OCTET STRING }
HashAlgAndValue ::= SEQUENCE {
hashAlg AlgorithmIdentifier,
hashValue OCTET STRING }
When using indirect addressing, the URI (refStructURI) pointing to the external data structure MUST point to a binary file containing the DER encoded data with the syntax LogotypeData. The referenced file name SHOULD include a file extension of "LTD".
使用间接寻址时，指向外部数据结构的URI（refStructURI）必须指向包含DER编码数据的二进制文件，其语法为LogotypeData。引用的文件名应包括文件扩展名“LTD”。
At least one of the optional elements in the LogotypeExtn structure MUST be present. Avoid the use of otherLogos whenever possible.
LogotypeExtn结构中必须至少存在一个可选元素。尽可能避免使用其他徽标。
The LogotypeReference and LogotypeDetails structures explicitly identify one or more one-way hash functions employed to authenticate referenced data files. Clients MUST support the SHA-1 [SHS] one-way hash function, and clients MAY support other one-way hash functions. CAs MUST include a SHA-1 hash value for each referenced file, calculated on the whole file, and CAs MAY include other one-way hash values. Clients MUST compute a one-way hash value using one of the identified functions, and clients MUST discard the logotype data if the computed one-way hash function value does not match the one-way hash function value in the certificate extension.
LogotypeReference和LogotypeDetails结构明确标识用于验证引用数据文件的一个或多个单向散列函数。客户端必须支持SHA-1[SHS]单向散列函数，并且客户端可以支持其他单向散列函数。CAs必须为每个引用的文件包含一个SHA-1散列值，该散列值是在整个文件上计算的，CAs可以包含其他单向散列值。客户端必须使用其中一个已标识函数计算单向哈希值，如果计算的单向哈希函数值与证书扩展中的单向哈希函数值不匹配，则客户端必须丢弃标识数据。
A MIME type is used to specify the format of the file containing the logotype data. Implementations MUST support both the JPEG and GIF image formats (with MIME types of "image/jpeg" and "image/gif" [MEDIA], respectively). Animated images SHOULD NOT be used. Implementations that support audio MUST support the MP3 audio format (with a MIME type of "audio/mpeg" [AUDIO/MPEG]). MIME types MAY include parameters.
MIME类型用于指定包含标识数据的文件的格式。实现必须同时支持JPEG和GIF图像格式（MIME类型分别为“image/JPEG”和“image/GIF”[MEDIA]）。不应使用动画图像。支持音频的实现必须支持MP3音频格式（MIME类型为“audio/mpeg”[audio/mpeg]）。MIME类型可能包括参数。
When language is specified, the language tag MUST use the RFC 3066 [LANGCODES] syntax.
指定语言时，语言标记必须使用RFC 3066[LANGCODES]语法。
Logotype types defined in this specification are:
本规范中定义的标识类型为：
Community Logotype: If communityLogos is present, the logotypes MUST represent one or more communities with which the certificate issuer is affiliated. The communityLogos MAY be present in an end entity certificate, a CA certificate, or an attribute certificate. The communityLogos contains a sequence of Community Logotypes, each representing a different community. If more than one Community logotype is present, they MUST be placed in order of preferred appearance. Some clients MAY choose to display a subset of the present community logos; therefore the placement within the sequence aids the client selection. The most preferred logotype MUST be first in the sequence, and the least preferred logotype MUST be last in the sequence.
社区标识：如果存在社区标识，则标识必须表示证书颁发者所属的一个或多个社区。CommunityLogo可能存在于最终实体证书、CA证书或属性证书中。communityLogos包含一系列社区标识，每个标识代表不同的社区。如果存在多个社区标识，则必须按照首选外观的顺序放置。一些客户可能会选择显示当前社区徽标的子集；因此，序列中的位置有助于客户选择。最优先的标识必须是序列中的第一个，最不优先的标识必须是序列中的最后一个。
Issuer Organization Logotype: If issuerLogo is present, the logotype MUST represent the issuer's organization. The logotype MUST be consistent with, and require the presence of, an organization name stored in the organization attribute in the issuer field (for either a public key certificate or attribute certificate). The issuerLogo MAY be present in an end entity certificate, a CA certificate, or an attribute certificate.
发卡机构组织标识：如果存在issuerLogo，则该标识必须代表发卡机构的组织。标识类型必须与“颁发者”字段中存储在“组织”属性中的组织名称一致，并且要求该组织名称存在（对于公钥证书或属性证书）。issuerLogo可能存在于最终实体证书、CA证书或属性证书中。
Subject Organization Logotype: If subjectLogo is present, the logotype MUST represent the subject's organization. The logotype MUST be consistent with, and require the presence of, an organization name stored in the organization attribute in the subject field (for either a public key certificate or attribute certificate). The subjectLogo MAY be present in an end entity certificate, a CA certificate, or an attribute certificate.
主体组织标识：如果存在主体标识，则标识必须代表主体组织。标识类型必须与主题字段中存储在组织属性中的组织名称一致，并且要求存在组织名称（对于公钥证书或属性证书）。subjectLogo可能存在于终端实体证书、CA证书或属性证书中。
The relationship between the subject organization and the subject organization logotype, and the relationship between the issuer and either the issuer organization logotype or the community logotype, are relationships asserted by the issuer. The policies and practices employed by the issuer to check subject organization logotypes or claims its issuer and community logotypes is outside the scope of this document.
主体组织与主体组织标识之间的关系，以及发行人与发行人组织标识或社区标识之间的关系，均为发行人声明的关系。发行人用于检查主题组织标识或声称其发行人和社区标识的政策和做法不在本文件范围内。
Logotypes identified by otherLogos (as defined in 4.1) can be used to enhance the display of logotypes and marks that represent partners, products, services, or any other characteristic associated with the certificate or its intended application environment when the standard logotype types are insufficient.
当标准标识类型不足时，由其他标识（定义见4.1）标识的标识可用于增强标识和标志的显示，这些标识和标志代表合作伙伴、产品、服务或与证书或其预期应用环境相关的任何其他特征。
The conditions and contexts of the intended use of these logotypes are defined at the discretion of the local client application.
这些标识的预期用途的条件和上下文由本地客户应用程序自行定义。
The following other logotype types are defined in this document:
本文件中定义了以下其他标识类型：
- Loyalty logotype - Certificate Background logotype
- 忠诚标识-证书背景标识
OID Definitions:
OID定义：
id-logo OBJECT IDENTIFIER ::= { id-pkix 20 }
id-logo OBJECT IDENTIFIER ::= { id-pkix 20 }
id-logo-loyalty OBJECT IDENTIFIER ::= { id-logo 1 }
id-logo-loyalty OBJECT IDENTIFIER ::= { id-logo 1 }
id-logo-background OBJECT IDENTIFIER ::= { id-logo 2 }
id-logo-background OBJECT IDENTIFIER ::= { id-logo 2 }
A loyalty logotype, if present, MUST contain a logotype associated with a loyalty program related to the certificate or its use. The relation between the certificate and the identified loyalty program is beyond the scope of this document. The logotype extension MAY contain more than one Loyalty logotype.
忠诚度标识（如果存在）必须包含与证书或其使用相关的忠诚度计划相关联的标识。证书与已确定的忠诚度计划之间的关系超出了本文件的范围。标识扩展可以包含多个忠诚标识。
The certificate background logotype, if present, MUST contain a graphical image intended as a background image for the certificate, and/or a general audio sequence for the certificate. The background image MUST allow black text to be clearly read when placed on top of the background image. The logotype extension MUST NOT contain more than one certificate background logotype.
证书背景标识（如果存在）必须包含用作证书背景图像的图形图像和/或证书的通用音频序列。背景图像放置在背景图像上方时，必须允许清晰地读取黑色文本。标识扩展不能包含多个证书背景标识。
Logotypes MAY be included in public key certificates and attribute certificates at the discretion of the certificate issuer; however, logotypes MUST NOT be part of certification path validation or any type of automated processing. The sole purpose of logotypes is to enhance the display of a particular certificate, regardless of its position in a certification path.
公钥证书和属性证书中可能包含标识类型，由证书颁发者自行决定；但是，标识类型不得作为认证路径验证或任何类型的自动处理的一部分。标识类型的唯一目的是增强特定证书的显示，而不管其在证书路径中的位置如何。
All PKI implementations require relying party software to have some mechanism to determine whether a trusted CA issues a particular certificate. This is an issue for certification path validation, including consistent policy and name checking.
所有PKI实现都要求依赖方软件具有某种机制来确定受信任CA是否颁发特定证书。这是认证路径验证的一个问题，包括一致性策略和名称检查。
After a certification path is successfully validated, the replying party trusts the information that the CA includes in the certificate, including any certificate extensions. The client software can choose to make use of such information, or the client software can ignore it. If the client is unable to support a provided logotype, the client MUST NOT report an error, rather the client MUST behave as though no logotype extension was included in the certificate. Current standards do not provide any mechanism for cross-certifying CAs to constrain subordinate CAs from including private extensions (see the security considerations section).
成功验证证书路径后，应答方信任CA在证书中包含的信息，包括任何证书扩展。客户端软件可以选择使用这些信息，也可以忽略这些信息。如果客户机无法支持提供的标识，则客户机不得报告错误，而必须表现为证书中未包含任何标识扩展。当前的标准没有为交叉认证CA提供任何机制来约束下级CA不包括私有扩展（请参阅安全注意事项一节）。
Consequently, if relying party software accepts a CA, then it should be prepared to (unquestioningly) display the associated logotypes to its human user, given that it is configured to do so. Information about the logotypes is provided so that the replying party software can select the one that will best meet the needs of the human user. This choice depends on the abilities of the human user, as well as the capabilities of the platform on which the replaying party software is running. If none of the provided logotypes meets the needs of the human user or matches the capabilities of the platform, then the logotypes can be ignored.
因此，如果依赖方软件接受CA，那么它应该准备（毫无疑问地）向其人类用户显示关联的标识类型，因为它被配置为这样做。提供有关标识类型的信息，以便回复方软件可以选择最能满足人类用户需求的标识。这种选择取决于人类用户的能力，以及运行回放方软件的平台的能力。如果所提供的任何标识都不能满足人类用户的需求或与平台的功能相匹配，则可以忽略这些标识。
A client MAY, subject to local policy, choose to display none, one, or any number of the logotypes in the logotype extension.
根据当地政策，客户可以选择在标识扩展中不显示、显示一个或任意数量的标识。
In many cases, a client will be used in an environment with a good network connection and also used in an environment with little or no network connectivity. For example, a laptop computer can be docked with a high-speed LAN connection, or it can be disconnected from the network altogether. In recognition of this situation, the client MUST include the ability to disable the fetching of logotypes. However, locally cached logotypes can still be displayed when the user disables the fetching of additional logotypes.
在许多情况下，客户端将在网络连接良好的环境中使用，也将在网络连接很少或没有网络连接的环境中使用。例如，笔记本电脑可以与高速局域网连接对接，也可以与网络完全断开连接。考虑到这种情况，客户端必须具备禁用获取标识类型的功能。但是，当用户禁用获取其他标识时，仍可以显示本地缓存的标识。
A client MAY, subject to local policy, choose any combination of audio and image presentation for each logotype. That is, the client MAY display an image with or without playing a sound, and it MAY play a sound with or without displaying an image. A client MUST NOT play more than one logotype audio sequence at the same time.
根据当地政策，客户可以为每个标识选择音频和图像显示的任意组合。也就是说，客户端可以显示带有或不带有声音的图像，并且它可以播放带有或不带有图像的声音。客户端不能同时播放多个标识音频序列。
The logotype is to be displayed in conjunction with other identity information contained in the certificate. The logotype is not a replacement for this identity information.
标识将与证书中包含的其他身份信息一起显示。该标识不是此标识信息的替代品。
Care is needed when designing replying party software to ensure that an appropriate context of logotype information is provided. This is especially difficult with audio logotypes. It is important that the human user be able to recognize the context of the logotype, even if other audio streams are being played.
在设计回复方软件时需要谨慎，以确保提供适当的标识信息上下文。这对于音频标识尤其困难。重要的是，人类用户能够识别标识的上下文，即使正在播放其他音频流。
If the relying party software is unable to successfully validate a particular certificate, then it MUST NOT display any logotype data associated with that certificate.
如果依赖方软件无法成功验证特定证书，则它不得显示与该证书相关的任何标识数据。
Implementations that simultaneously display multiple logotype types (subject organization, issuer, community or other), MUST ensure that there is no ambiguity as to the binding between the image and the type of logotype that the image represents. "Logotype type" is defined in section 2, and it refers to the type of entity or affiliation represented by the logotype, not the type of binary format.
同时显示多种标识类型（主体组织、发行人、社区或其他）的实现必须确保图像与图像所代表的标识类型之间的绑定不存在歧义。“标识类型”在第2节中有定义，它是指标识所代表的实体或附属机构的类型，而不是二进制格式的类型。
Logotypes are very difficult to securely and accurately define. Names are also difficult in this regard, but logotypes are even worse. It is quite difficult to specify what is, and what is not, a legitimate logotype of an organization. There is an entire legal structure around this issue, and it will not be repeated here. However, issuers should be aware of the implications of including images associated with a trademark or servicemark before doing so.
标识类型很难安全准确地定义。在这方面，名字也很难，但标识更糟糕。很难指定什么是组织的合法标识，什么不是。围绕这个问题有一个完整的法律结构，这里不再重复。然而，发行人在这样做之前应该意识到包含与商标或服务商标相关的图像的含义。
As logotypes can be difficult (and sometimes expensive) to verify, the possibility of errors related to assigning wrong logotypes to organizations is increased.
由于标识类型很难验证（有时很昂贵），因此与向组织分配错误标识相关的错误可能性增加。
This is not a new issue for electronic identification instruments. It is already dealt with in a number of similar situations in the physical world, including physical employee identification cards. Secondly, there are situations where identification of logotypes is rather simple and straightforward, such as logotypes for well-known industries and institutes. These issues should not stop those service providers who want to issue logotypes from doing so, where relevant.
对于电子识别仪器来说，这不是一个新问题。它已经在物理世界中的许多类似情况下得到处理，包括物理员工身份证。其次，在一些情况下，标识非常简单和直接，例如知名行业和机构的标识。这些问题不应该阻止那些想要发布标识的服务提供商这样做，如果相关的话。
It is impossible to prevent fraudulent creation of certificates by dishonest or badly performing issuers, containing names and logotypes that the issuer has no claim to or has failed to check correctly. Such certificates could be created in an attempt to socially engineer a user into accepting a certificate. The premise used for the logotype work is thus that logotype graphics in a certificate are trusted only if the certificate is successfully validated within a valid path. It is thus imperative that the representation of any certificate that fails to validate is not enhanced in any way by using the logotype graphic.
无法防止不诚实或表现不佳的发行人欺诈性地创建证书，其中包含发行人没有要求或未能正确检查的名称和标识。创建此类证书的目的可能是试图通过社会工程让用户接受证书。因此，用于标识工作的前提是，仅当证书在有效路径内成功验证时，证书中的标识图形才可信。因此，不能通过使用标识图形以任何方式增强任何无法验证的证书的表示。
Logotype data is fetched from a server when it is needed. By watching activity on the network, an observer can determine which clients are making use of certificates that contain particular logotype data. This observation can potentially introduce privacy issues. Since clients are expected to locally cache logotype data, network traffic to the server containing the logotype data will not be generated every time the certificate is used. In cases where logotype data is not cashed, monitoring would reveal usage frequency. In cases where logotype data is cached, monitoring would reveal when a certain logotype image or audio sequence is used for the first time.
当需要时，从服务器获取标识数据。通过观察网络上的活动，观察者可以确定哪些客户端正在使用包含特定标识数据的证书。这种观察可能会带来隐私问题。由于客户端需要本地缓存标识数据，因此不会在每次使用证书时生成到包含标识数据的服务器的网络流量。在标识数据未兑现的情况下，监控将显示使用频率。在缓存标识数据的情况下，监控将显示某个标识图像或音频序列何时首次使用。
Certification paths may also impose name constraints that are systematically checked during certification path processing, which, in theory, may be circumvented by logotypes.
认证路径还可能施加在认证路径处理过程中系统检查的名称约束，从理论上讲，这可能会被标识规避。
Certificate path processing as defined in RFC 3280 [PKIX-1] does not constrain the inclusion of logotype data in certificates. A parent CA can constrain certification path validation such that subordinate CAs cannot issue valid certificates to end-entities outside a limited name space or outside specific certificate polices. A malicious CA can comply with these name and policy requirements and still include inappropriate logotypes in the certificates that it issues. These certificates will pass the certification path validation algorithm,
RFC 3280[PKIX-1]中定义的证书路径处理不限制在证书中包含标识数据。父CA可以约束证书路径验证，以便下级CA无法向有限名称空间或特定证书策略之外的最终实体颁发有效证书。恶意CA可以遵守这些名称和策略要求，并且在其颁发的证书中仍然包含不适当的标识。这些证书将通过证书路径验证算法，
which means the client will trust the logotypes in the certificates. Since there is no technical mechanism to prevent or control subordinate CAs from including the logotype extension or its contents, where appropriate, a parent CA could employ a legal agreement to impose a suitable restriction on the subordinate CA. This situation is not unique to the logotype extension.
这意味着客户端将信任证书中的标识类型。由于没有技术机制阻止或控制下级CA包括标识扩展或其内容，因此在适当的情况下，上级CA可以利用法律协议对下级CA施加适当的限制。这种情况并非标识扩展所独有。
The controls available to a parent CA to protect itself from rogue subordinate CAs are non-technical. They include:
父CA可用于保护自身免受流氓下级CA攻击的控件是非技术性的。这些措施包括：
- Contractual agreements of suitable behavior, including terms of liability in case of material breach.
- 适当行为的合同协议，包括重大违约的责任条款。
- Control mechanisms and procedures to monitor and follow-up behavior of subordinate CAs.
- 监控和跟踪下属CA行为的控制机制和程序。
- Use of certificate policies to declare an assurance level of logotype data, as well as to guide applications on how to treat and display logotypes.
- 使用证书策略声明标识数据的保证级别，并指导应用程序如何处理和显示标识。
- Use of revocation functions to revoke any misbehaving CA.
- 使用撤销功能撤销任何行为不当的CA。
There is not a simple, straightforward, and absolute technical solution. Rather, involved parties must settle some aspects of PKI outside the scope of technical controls. As such, issuers need to clearly identify and communicate the associated risks.
没有简单、直接和绝对的技术解决方案。相反，参与方必须解决技术控制范围之外的PKI的某些方面。因此，发行人需要明确识别和传达相关风险。
Certificate extensions and attribute certificate extensions are identified by object identifiers (OIDs). The OID for the extension defined in this document was assigned from an arc delegated by the IANA to the PKIX Working Group. No further action by the IANA is necessary for this document or any anticipated updates.
证书扩展和属性证书扩展由对象标识符（OID）标识。本文件中定义的扩展的OID由IANA委托给PKIX工作组的arc分配。IANA无需对本文件或任何预期更新采取进一步行动。
This document is the result of contributions from many professionals. The authors appreciate contributions from all members of the IETF PKIX Working Group. We extend a special thanks to Al Arsenault, David Cross, Tim Polk, Russel Weiser, Terry Hayes, Alex Deacon, Andrew Hoag, Randy Sabett, Denis Pinkas, Magnus Nystrom, Ryan Hurst, and Phil Griffin for their efforts and support.
本文件是许多专业人士贡献的成果。作者感谢IETF PKIX工作组所有成员的贡献。我们特别感谢阿尔·阿塞诺、大卫·克罗斯、蒂姆·波尔克、罗素·韦瑟、特里·海斯、亚历克斯·迪肯、安德鲁·霍格、兰迪·萨贝特、丹尼斯·平卡斯、马格纳斯·尼斯特罗姆、瑞安·赫斯特和菲尔·格里芬的努力和支持。
Russ Housley thanks the management at RSA Laboratories, especially Burt Kaliski, who supported the development of this specification. The vast majority of the work on this specification was done while Russ was employed at RSA Laboratories.
Russ Housley感谢RSA实验室的管理层，特别是Burt Kaliski，他支持本规范的开发。本规范的绝大多数工作是在RSA实验室使用RUS时完成的。
[LANGCODES] Alvestrand, H., "Tags for Identification of Languages", BCP 47, RFC 3066, January 2001.
[LANGCODES]Alvestrand，H.，“语言识别标签”，BCP 47，RFC 3066，2001年1月。
[PKIX-1] 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.
[PKIX-1]Housley，R.，Polk，W.，Ford，W.和D.Solo，“互联网X.509公钥基础设施：证书和证书撤销列表（CRL）概要”，RFC 32802002年4月。
[PKIX-AC] Farrell, S. and R. Housley, "An Internet Attribute Certificate Profile for Authorization", RFC 3281, April 2002.
[PKIX-AC]Farrell，S.和R.Housley，“用于授权的Internet属性证书配置文件”，RFC 3281，2002年4月。
[SHS] Federal Information Processing Standards Publication (FIPS PUB) 180-1, Secure Hash Standard, 17 April 1995. [Supersedes FIPS PUB 180 dated 11 May 1993.]
[SHS]联邦信息处理标准出版物（FIPS PUB）180-1，安全哈希标准，1995年4月17日。[取代1993年5月11日发布的FIPS PUB 180。]
[STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[STDWORDS]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[HTTP/1.1] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[HTTP/1.1]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗里斯蒂克，H.，马斯滕特，L.，利奇P.和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC2616，1999年6月。
[FTP] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.
[FTP]Postel，J.和J.Reynolds，“文件传输协议”，STD 9，RFC 959，1985年10月。
[URI] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[URI]Berners Lee，T.，Fielding，R.和L.Masinter，“统一资源标识符（URI）：通用语法”，RFC 2396，1998年8月。
[MEDIA] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[MEDIA]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第二部分：媒体类型”，RFC 20461996年11月。
[AUDIO/MPEG] Nilsson, M., "The audio/mpeg Media Type", RFC 3003, November 2000.
[AUDIO/MPEG]Nilsson，M.，“音频/MPEG媒体类型”，RFC 3003，2000年11月。
[X.509] ITU-T Recommendation X.509 (2000) | ISO/IEC 9594-8:2001, Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks
[X.509]ITU-T建议X.509（2000）| ISO/IEC 9594-8:2001，信息技术-开放系统互连-目录：公钥和属性证书框架
APPENDIX A. ASN.1 Module
附录A.ASN.1模块
LogotypeCertExtn
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-logotype(22) }
LogotypeCertExtn
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-logotype(22) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
AlgorithmIdentifier FROM PKIX1Explicit88 -- RFC 3280
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit(18) };
IMPORTS
AlgorithmIdentifier FROM PKIX1Explicit88 -- RFC 3280
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit(18) };
-- Logotype Extension OID
--标识扩展OID
id-pe-logotype OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-pe(1) 12 }
id-pe-logotype OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-pe(1) 12 }
-- Logotype Extension Syntax
--标识扩展语法
LogotypeExtn ::= SEQUENCE {
communityLogos [0] EXPLICIT SEQUENCE OF LogotypeInfo OPTIONAL,
issuerLogo [1] EXPLICIT LogotypeInfo OPTIONAL,
subjectLogo [2] EXPLICIT LogotypeInfo OPTIONAL,
otherLogos [3] EXPLICIT SEQUENCE OF OtherLogotypeInfo OPTIONAL }
LogotypeExtn ::= SEQUENCE {
communityLogos [0] EXPLICIT SEQUENCE OF LogotypeInfo OPTIONAL,
issuerLogo [1] EXPLICIT LogotypeInfo OPTIONAL,
subjectLogo [2] EXPLICIT LogotypeInfo OPTIONAL,
otherLogos [3] EXPLICIT SEQUENCE OF OtherLogotypeInfo OPTIONAL }
LogotypeInfo ::= CHOICE {
direct [0] LogotypeData,
indirect [1] LogotypeReference }
LogotypeInfo ::= CHOICE {
direct [0] LogotypeData,
indirect [1] LogotypeReference }
LogotypeData ::= SEQUENCE {
image SEQUENCE OF LogotypeImage OPTIONAL,
audio [1] SEQUENCE OF LogotypeAudio OPTIONAL }
LogotypeData ::= SEQUENCE {
image SEQUENCE OF LogotypeImage OPTIONAL,
audio [1] SEQUENCE OF LogotypeAudio OPTIONAL }
LogotypeImage ::= SEQUENCE {
imageDetails LogotypeDetails,
imageInfo LogotypeImageInfo OPTIONAL }
LogotypeImage ::= SEQUENCE {
imageDetails LogotypeDetails,
imageInfo LogotypeImageInfo OPTIONAL }
LogotypeAudio ::= SEQUENCE {
audioDetails LogotypeDetails,
audioInfo LogotypeAudioInfo OPTIONAL }
LogotypeAudio ::= SEQUENCE {
audioDetails LogotypeDetails,
audioInfo LogotypeAudioInfo OPTIONAL }
LogotypeDetails ::= SEQUENCE {
mediaType IA5String, -- MIME media type name and optional
-- parameters
logotypeHash SEQUENCE SIZE (1..MAX) OF HashAlgAndValue,
logotypeURI SEQUENCE SIZE (1..MAX) OF IA5String }
LogotypeDetails ::= SEQUENCE {
mediaType IA5String, -- MIME media type name and optional
-- parameters
logotypeHash SEQUENCE SIZE (1..MAX) OF HashAlgAndValue,
logotypeURI SEQUENCE SIZE (1..MAX) OF IA5String }
LogotypeImageInfo ::= SEQUENCE {
type [0] LogotypeImageType DEFAULT color,
fileSize INTEGER, -- In octets
xSize INTEGER, -- Horizontal size in pixels
ySize INTEGER, -- Vertical size in pixels
resolution LogotypeImageResolution OPTIONAL,
language [4] IA5String OPTIONAL } -- RFC 3066 Language Tag
LogotypeImageInfo ::= SEQUENCE {
type [0] LogotypeImageType DEFAULT color,
fileSize INTEGER, -- In octets
xSize INTEGER, -- Horizontal size in pixels
ySize INTEGER, -- Vertical size in pixels
resolution LogotypeImageResolution OPTIONAL,
language [4] IA5String OPTIONAL } -- RFC 3066 Language Tag
LogotypeImageType ::= INTEGER { grayScale(0), color(1) }
LogotypeImageType ::= INTEGER { grayScale(0), color(1) }
LogotypeImageResolution ::= CHOICE {
numBits [1] INTEGER, -- Resolution in bits
tableSize [2] INTEGER } -- Number of colors or grey tones
LogotypeImageResolution ::= CHOICE {
numBits [1] INTEGER, -- Resolution in bits
tableSize [2] INTEGER } -- Number of colors or grey tones
LogotypeAudioInfo ::= SEQUENCE {
fileSize INTEGER, -- In octets
playTime INTEGER, -- In milliseconds
channels INTEGER, -- 1=mono, 2=stereo, 4=quad
sampleRate [3] INTEGER OPTIONAL, -- Samples per second
language [4] IA5String OPTIONAL } -- RFC 3066 Language Tag
LogotypeAudioInfo ::= SEQUENCE {
fileSize INTEGER, -- In octets
playTime INTEGER, -- In milliseconds
channels INTEGER, -- 1=mono, 2=stereo, 4=quad
sampleRate [3] INTEGER OPTIONAL, -- Samples per second
language [4] IA5String OPTIONAL } -- RFC 3066 Language Tag
OtherLogotypeInfo ::= SEQUENCE {
logotypeType OBJECT IDENTIFIER,
info LogotypeInfo }
OtherLogotypeInfo ::= SEQUENCE {
logotypeType OBJECT IDENTIFIER,
info LogotypeInfo }
LogotypeReference ::= SEQUENCE {
refStructHash SEQUENCE SIZE (1..MAX) OF HashAlgAndValue,
refStructURI SEQUENCE SIZE (1..MAX) OF IA5String }
-- Places to get the same "LTD" file
LogotypeReference ::= SEQUENCE {
refStructHash SEQUENCE SIZE (1..MAX) OF HashAlgAndValue,
refStructURI SEQUENCE SIZE (1..MAX) OF IA5String }
-- Places to get the same "LTD" file
-- Note: The content of referenced "LTD" files is defined by the
-- LogotypeData type
-- Note: The content of referenced "LTD" files is defined by the
-- LogotypeData type
HashAlgAndValue ::= SEQUENCE {
hashAlg AlgorithmIdentifier,
hashValue OCTET STRING }
HashAlgAndValue ::= SEQUENCE {
hashAlg AlgorithmIdentifier,
hashValue OCTET STRING }
-- Other logotype type OIDs
--其他标识类型
id-logo OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) 20 }
id-logo OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) 20 }
id-logo-loyalty OBJECT IDENTIFIER ::= { id-logo 1 }
id-logo-loyalty OBJECT IDENTIFIER ::= { id-logo 1 }
id-logo-background OBJECT IDENTIFIER ::= { id-logo 2 }
id-logo-background OBJECT IDENTIFIER ::= { id-logo 2 }
END
终止
APPENDIX B. Example Extension
附录B.扩展示例
The following example displays a logotype extension containing one Issuer logotype using direct addressing. The issuer logotype image is of the type image/gif. The logotype image file is referenced through 1 URI and the image is hashed by one sha1 hash value.
以下示例显示一个标识扩展，其中包含一个使用直接寻址的颁发者标识。发卡机构标识图像的类型为image/gif。logotype图像文件通过1个URI引用，图像由一个sha1散列值散列。
The values on the left are the ASN.1 tag and length, in hexadecimal.
左边的值是ASN.1标记和长度，以十六进制表示。
30 106: SEQUENCE {
06 8: OBJECT IDENTIFIER '1 3 6 1 5 5 7 1 12'
04 94: OCTET STRING, encapsulates {
30 92: SEQUENCE {
A1 90: [1] {
A0 88: [0] {
30 86: SEQUENCE {
30 84: SEQUENCE {
30 82: SEQUENCE {
16 9: IA5String 'image/gif'
30 33: SEQUENCE {
30 31: SEQUENCE {
30 7: SEQUENCE {
06 5: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26)
: }
04 20: OCTET STRING
: 8F E5 D3 1A 86 AC 8D 8E 6B C3 CF 80 6A D4 48 18
: 2C 7B 19 2E
: }
: }
30 34: SEQUENCE {
16 32: IA5String 'http://logo.example.com/logo.gif'
: }
: }
: }
: }
: }
: }
: }
: }
: }
30 106: SEQUENCE {
06 8: OBJECT IDENTIFIER '1 3 6 1 5 5 7 1 12'
04 94: OCTET STRING, encapsulates {
30 92: SEQUENCE {
A1 90: [1] {
A0 88: [0] {
30 86: SEQUENCE {
30 84: SEQUENCE {
30 82: SEQUENCE {
16 9: IA5String 'image/gif'
30 33: SEQUENCE {
30 31: SEQUENCE {
30 7: SEQUENCE {
06 5: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26)
: }
04 20: OCTET STRING
: 8F E5 D3 1A 86 AC 8D 8E 6B C3 CF 80 6A D4 48 18
: 2C 7B 19 2E
: }
: }
30 34: SEQUENCE {
16 32: IA5String 'http://logo.example.com/logo.gif'
: }
: }
: }
: }
: }
: }
: }
: }
: }
Authors' Addresses
作者地址
Stefan Santesson Microsoft Denmark Tuborg Boulevard 12 DK-2900 Hellerup Denmark
Stefan Santesson微软丹麦图堡大道12号DK-2900 Hellerup丹麦
EMail: stefans@microsoft.com
EMail: stefans@microsoft.com
Russell Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA
Russell Housley Vigil Security，LLC 918 Spring Knoll Drive Herndon，弗吉尼亚州，邮编20170
EMail: housley@vigilsec.com
EMail: housley@vigilsec.com
Trevor Freeman Microsoft Corporation One Microsoft Way Redmond WA 98052 USA
特雷弗·弗里曼微软公司美国华盛顿州雷德蒙微软大道一号，邮编：98052
EMail: trevorf@microsoft.com
EMail: trevorf@microsoft.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2004). 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.
版权所有（C）互联网协会（2004年）。本文件受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 currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。