Network Working Group J. Park
Request for Comments: 4683 J. Lee
Category: Standards Track H. Lee
KISA
S. Park
BCQRE
T. Polk
NIST
October 2006
Network Working Group J. Park
Request for Comments: 4683 J. Lee
Category: Standards Track H. Lee
KISA
S. Park
BCQRE
T. Polk
NIST
October 2006
Internet X.509 Public Key Infrastructure Subject Identification Method (SIM)
Internet X.509公钥基础设施主体识别方法（SIM）
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 defines the Subject Identification Method (SIM) for including a privacy-sensitive identifier in the subjectAltName extension of a certificate.
本文档定义了用于在证书的subjectAltName扩展中包含隐私敏感标识符的SubjectIdentification Method（SIM）。
The SIM is an optional feature that may be used by relying parties to determine whether the subject of a particular certificate is also the person corresponding to a particular sensitive identifier.
SIM是一种可选功能，依赖方可以使用它来确定特定证书的主体是否也是与特定敏感标识符相对应的人。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Key Words ..................................................5
2. Symbols .........................................................6
3. Requirements ....................................................6
3.1. Security Requirements ......................................6
3.2. Usability Requirements .....................................7
3.3. Solution ...................................................7
4. Procedures ......................................................8
4.1. SII and SIItype ............................................8
4.2. User Chosen Password .......................................9
4.3. Random Number Generation ...................................9
4.4. Generation of SIM ..........................................9
4.5. Encryption of PEPSI .......................................10
4.6. Certification Request .....................................10
4.7. Certification .............................................11
5. Definition .....................................................11
5.1. SIM Syntax ................................................11
5.2. PEPSI .....................................................12
5.3. Encrypted PEPSI ...........................................12
6. Example Usage of SIM ...........................................13
7. Name Constraints ...............................................13
8. Security Considerations ........................................14
9. Acknowledgements ...............................................15
10. IANA Considerations ...........................................15
11. References ....................................................15
11.1. Normative References .....................................15
11.2. Informative References ...................................15
Appendix A. "Compilable" ASN.1 Module, 1988 Syntax ...............18
1. Introduction ....................................................2
1.1. Key Words ..................................................5
2. Symbols .........................................................6
3. Requirements ....................................................6
3.1. Security Requirements ......................................6
3.2. Usability Requirements .....................................7
3.3. Solution ...................................................7
4. Procedures ......................................................8
4.1. SII and SIItype ............................................8
4.2. User Chosen Password .......................................9
4.3. Random Number Generation ...................................9
4.4. Generation of SIM ..........................................9
4.5. Encryption of PEPSI .......................................10
4.6. Certification Request .....................................10
4.7. Certification .............................................11
5. Definition .....................................................11
5.1. SIM Syntax ................................................11
5.2. PEPSI .....................................................12
5.3. Encrypted PEPSI ...........................................12
6. Example Usage of SIM ...........................................13
7. Name Constraints ...............................................13
8. Security Considerations ........................................14
9. Acknowledgements ...............................................15
10. IANA Considerations ...........................................15
11. References ....................................................15
11.1. Normative References .....................................15
11.2. Informative References ...................................15
Appendix A. "Compilable" ASN.1 Module, 1988 Syntax ...............18
A Certification Authority (CA) issues X.509 public key certificates to bind a public key to a subject. The subject is specified through one or more subject names in the "subject" or "subjectAltName" fields of a certificate. The "subject" field contains a hierarchically structured distinguished name. The "subjectAltName field" may contain an electronic mail address, IP address, or other name forms that correspond to the subject.
证书颁发机构（CA）颁发X.509公钥证书以将公钥绑定到主题。通过证书“subject”或“subjectAltName”字段中的一个或多个subject名称指定subject。“主题”字段包含分层结构的可分辨名称。“subjectAltName字段”可能包含电子邮件地址、IP地址或与主题对应的其他名称形式。
For each particular CA, a subject name corresponds to a unique person, device, group, or role. The CA will not knowingly issue certificates to multiple entities under the same subject name. That is, for a particular certificate issuer, all currently valid certificates asserting the same subject name(s) are bound to the same entity.
对于每个特定CA，主题名称对应于唯一的个人、设备、组或角色。CA不会故意以同一主题名称向多个实体颁发证书。也就是说，对于特定的证书颁发者，断言相同主题名称的所有当前有效证书都绑定到同一实体。
Where the subject is a person, the name that is specified in the subject field of the certificate may reflect the name of the individual and affiliated entities (e.g., their corporate affiliation). In reality, however, there are individuals or corporations that have the same or similar names. It may be difficult for a relying party (e.g., a person or application) to associate the certificate with a specific person or organization based solely on the subject name. This ambiguity presents a problem for many applications.
如果主体是个人，则证书主体字段中指定的名称可能反映个人和关联实体的名称（例如，其公司关联）。然而，在现实中，有些个人或公司的名字相同或相似。依赖方（例如，个人或申请）可能难以仅根据主体名称将证书与特定个人或组织关联。这种模糊性给许多应用程序带来了问题。
In some cases, applications or relying parties need to ensure that the subject of certificates issued by different CAs are in fact the same entity. This requirement may be met by including a "permanent identifier" in all certificates issued to the same subject, which is unique across multiple CAs. By comparing the "permanent identifier", the relying party may identify certificates from different CAs that are bound to the same subject. This solution is defined in [RFC 4043].
在某些情况下，应用程序或依赖方需要确保不同CA颁发的证书的主体实际上是同一实体。可通过在颁发给同一主体的所有证书中包含“永久标识符”来满足该要求，该标识符在多个CA中是唯一的。通过比较“永久标识符”，依赖方可以识别来自绑定到同一主题的不同CA的证书。此解决方案在[RFC 4043]中定义。
In many cases, a person's or corporation's identifier (e.g., a Social Security Number) is regarded as sensitive, private, or personal data. Such an identifier cannot simply be included as part of the subject field, since its disclosure may lead to misuse. Therefore, privacy-sensitive identifiers of this sort should not be included in certificates in plaintext form.
在许多情况下，个人或公司的标识符（如社会保险号码）被视为敏感、私人或个人数据。此类标识符不能简单地作为主题字段的一部分，因为其披露可能导致误用。因此，此类隐私敏感标识符不应包含在明文形式的证书中。
On the other hand, such an identifier is not actually a secret. People choose to disclose these identifiers for certain classes of transactions. For example, a person may disclose a Social Security Number to open a bank account or obtain a loan. This is typically corroborated by presenting physical credentials (e.g., a driver's license) that confirm the person's name or address.
另一方面，这样的标识符实际上不是秘密。人们选择为特定类别的交易披露这些标识符。例如，一个人可能会披露一个社会保险号码以开立银行账户或获得贷款。这通常通过出示确认此人姓名或地址的实体凭证（如驾驶执照）来证实。
To support such applications in an online environment, relying parties need to determine whether the subject of a particular certificate is also the person corresponding to a particular sensitive identifier. Ideally, applications would leverage the applicants' electronic credential (e.g., the X.509 public key certificate) to corroborate this identifier, but the subject field of a certificate often does not provide sufficient information.
为了在在线环境中支持此类应用程序，依赖方需要确定特定证书的主体是否也是与特定敏感标识符对应的人。理想情况下，应用程序将利用申请人的电子凭证（例如，X.509公钥证书）来证实该标识符，但证书的主题字段通常不能提供足够的信息。
To fulfill these demands, this specification defines the Subject Identification Method (SIM) and the Privacy-Enhanced Protected Subject Information (PEPSI) format for including a privacy sensitive identifier in a certificate. Although other solutions for binding privacy-sensitive identifiers to a certificate could be developed, the method specified in this document has especially attractive properties. This specification extends common PKI practices and
为了满足这些要求，本规范定义了主体识别方法（SIM）和隐私增强受保护主体信息（PEPI）格式，用于在证书中包含隐私敏感标识符。尽管可以开发其他将隐私敏感标识符绑定到证书的解决方案，但本文档中指定的方法具有特别吸引人的特性。本规范扩展了常见的PKI实践和
mechanisms to allow privacy-sensitive identifiers to be included in the certificate as well. The SIM mechanism also permits the subject to control exposure of the sensitive identifier; when the subject chooses to expose the sensitive identifier, relying parties can verify the binding. Specifically:
允许在证书中包含隐私敏感标识符的机制。SIM机制还允许对象控制敏感标识符的暴露；当主体选择公开敏感标识符时，依赖方可以验证绑定。明确地：
(1) A Public Key Infrastructure (PKI) depends upon a trusted third party -- the CA -- to bind one or more identities to a public key. Traditional PKI implementations bind X.501 distinguished names to the public key, but identity may also be specified in terms of RFC 822 addresses or DNS names. The SIM specification allows the same trusted third party -- the CA -- that binds a name to the public key to include a privacy-sensitive identifier in the certificate as well. Since the relying party (RP) already trusts the CA to issue certificates, it is a simple extension to cover verification and binding of a sensitive identifier as well. This binding could be established separately, by another trusted third party, but this would complicate the infrastructure.
(1) 公钥基础设施（PKI）依赖于可信的第三方（CA）将一个或多个身份绑定到公钥。传统的PKI实现将X.501可分辨名称绑定到公钥，但也可以根据RFC 822地址或DNS名称指定标识。SIM规范允许将名称绑定到公钥的同一可信第三方CA在证书中也包含隐私敏感标识符。由于依赖方（RP）已经信任CA来颁发证书，因此它是一个简单的扩展，可以涵盖敏感标识符的验证和绑定。此绑定可以由另一个受信任的第三方单独建立，但这会使基础架构复杂化。
(2) This specification leverages standard PKI extensions to achieve new functional goals with a minimum of new code. This specification encodes the sensitive identifier in the otherName field in the alternative subject name extension. Since otherName field is widely used, this solution leverages a certificate field that is often populated and processed. (For example, smart card logon implementations generally rely upon names encoded in this field.) Whereas implementations of this specification will require some SIM-specific code, an alternative format would increase cost without enhancing security. In addition, that has no impact on implementations that do not process sensitive identifiers.
(2) 本规范利用标准PKI扩展，以最少的新代码实现新的功能目标。此规范在备选主题名称扩展名的otherName字段中对敏感标识符进行编码。由于otherName字段被广泛使用，此解决方案利用了经常填充和处理的证书字段。（例如，智能卡登录实现通常依赖于在此字段中编码的名称。）虽然此规范的实现将需要一些特定于SIM卡的代码，但另一种格式将在不增强安全性的情况下增加成本。此外，这对不处理敏感标识符的实现没有影响。
(3) By explicitly binding the public key to the identifier, this specification allows the relying party to confirm the claimant's identifier and confirm that the claimant is the subject of that identifier. That is, proof of possession of the private key confirms that the claimant is the same person whose identity was confirmed by the PKI (CA or RA, depending upon the architecture).
(3) 通过将公钥明确绑定到标识符，本规范允许依赖方确认索赔人的标识符，并确认索赔人是该标识符的主体。也就是说，拥有私钥的证据确认索赔人是同一个人，其身份已由PKI确认（CA或RA，取决于体系结构）。
To achieve the same goal in a separate message (e.g., a signed and encrypted Secure MIME (S/MIME) object), the message would need to be bound to the certificate or an identity in the certificate (e.g., the X.501 distinguished name). The former solution is problematic, since certificates expire. The latter solution may cause problems if names are ever reused in the infrastructure. An explicit binding in the certificate is a simpler solution, and more reliable.
为了在单独的消息（例如，签名和加密的安全MIME（S/MIME）对象）中实现相同的目标，需要将消息绑定到证书或证书中的标识（例如，X.501可分辨名称）。前一种解决方案是有问题的，因为证书过期了。如果在基础结构中重用名称，后一种解决方案可能会导致问题。证书中的显式绑定是一种更简单、更可靠的解决方案。
(4) This specification allows the subject of the privacy-sensitive identifier to control the distribution and level of security applied to the identifier. The identifier is only disclosed when the subject chooses to disclose it, even if the certificate is posted in a public directory. By choosing a strong password, the subject can ensure that the identifier is protected against brute force attacks. This specification permits subjects to selectively disclose an identifier where they deem it appropriate, which is consistent with common use of such identifiers.
(4) 本规范允许隐私敏感标识符的主体控制应用于标识符的分布和安全级别。只有当主体选择公开该标识符时，才会公开该标识符，即使证书发布在公共目录中也是如此。通过选择强密码，主体可以确保标识符受到暴力攻击的保护。本规范允许受试者在其认为合适的情况下选择性地披露标识符，这与此类标识符的常用用法一致。
(5) Certificates that contain a sensitive identifier may still be used to support other applications. A party that obtains a certificate containing a sensitive identifier, but to whom the subject does not choose to disclose the identifier, must perform a brute force attack to obtain the identifier. By selecting a strong hash algorithm, this attack becomes computationally infeasible. Moreover, when certificates include privacy-sensitive identifiers as described in this specification, each certificate must be attacked separately. Finally, the subjects can use this mechanism to prove they possess a certificate containing a particular type of identifier without actually disclosing it to the relying party.
(5) 包含敏感标识符的证书仍可用于支持其他应用程序。获取包含敏感标识符的证书但主体不选择向其披露该标识符的一方，必须执行暴力攻击以获取该标识符。通过选择强哈希算法，这种攻击在计算上变得不可行。此外，当证书包括本规范中描述的隐私敏感标识符时，必须单独攻击每个证书。最后，受试者可以使用这一机制证明他们拥有包含特定类型标识符的证书，而无需实际向依赖方披露。
This feature MUST be used only in conjunction with protocols that make use of digital signatures generated using the subject's private key.
此功能只能与使用主体私钥生成的数字签名的协议结合使用。
In addition, this document defines an Encrypted PEPSI (EPEPSI) so that sensitive identifier information can be exchanged during certificate issuance processes without disclosing the identifier to an eavesdropper.
此外，本文件定义了加密的百事可乐（EPEPSI），以便在证书颁发过程中交换敏感的标识符信息，而无需向窃听者披露标识符。
This document is organized as follows:
本文件的组织结构如下：
- Section 3 establishes security and usability requirements; - Section 4 provides an overview of the mechanism; - Section 5 defines syntax and generation rules; and - Section 6 provides example use cases.
- 第3节规定了安全性和可用性要求；-第4节概述了该机制；-第5节定义了语法和生成规则；和-第6节提供了示例用例。
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]中所述进行解释。
The following cryptography symbols are defined in this document.
本文件中定义了以下加密符号。
H() Cryptographically secure hash algorithm. SHA-1 [FIPS 180-1] or a more secure hash function is required.
H（）加密安全哈希算法。需要SHA-1[FIPS 180-1]或更安全的哈希函数。
SII Sensitive Identification Information (e.g., Social Security Number).
SII敏感身份信息（如社会保险号）。
SIItype Object Identifier that identifies the type of SII.
标识SII类型的SIItype对象标识符。
P A user-chosen password.
P用户选择的密码。
R The random number value generated by a Registration Authority (RA).
R由注册机构（RA）生成的随机数值。
PEPSI Privacy-Enhanced Protected Subject Information. Calculated from the input value P, R, SIItype, SII using two iteration of H().
百事隐私增强受保护的主题信息。使用H（）的两次迭代从输入值P、R、SIItype、SII计算得出。
E() The encryption algorithm to encrypt the PEPSI value.
E（）加密PEPSI值的加密算法。
EPEPSI Encrypted PEPSI.
EPEPSI加密百事可乐。
D() The decryption algorithm to decrypt the EPEPSI.
D（）用于解密EPSI的解密算法。
We make the following assumptions about the context in which SIM and PEPSI are to be employed:
我们对SIM卡和百事可乐的使用环境做出以下假设：
- Alice, a certificate holder, with a sensitive identifier SIIa (such as her Social Security Number) - Bob, a relying party who will require knowledge of Alice's SIIa - Eve, an attacker who acquires Alice's certificate - An RA to whom Alice must divulge her SIIa - A CA who will issue Alice's certificate
- Alice是一名证书持有人，具有敏感标识符SIIa（如她的社会保险号）——Bob，一名需要了解Alice的SIIa-Eve的依赖方，一名获得Alice证书的攻击者——Alice必须向其透露其SIIa的RA——一名将颁发Alice证书的CA
We wish to design SIM and PEPSI, using a password that Alice chooses, that has the following properties:
我们希望使用Alice选择的密码设计SIM卡和百事可乐，该密码具有以下属性：
- Alice can prove her SII, SIIa to Bob.
- 艾丽丝可以向鲍勃证明她的SII，SIA。
- Eve has a large work factor to determine Alice's SIIa from Alice's certificate, even if Alice chooses a weak password, and a very large work factor if Alice chooses a good password. - Even if Eve can determine SIIa, she has an equally hard problem to find any other SII values from any other PEPSI; that is, there is nothing she can pre-compute that helps her attack PEPSIs in other certificates, and nothing she learns from a successful attack that helps in any other attack. - The CA does not learn Alice's SIIa except in the case where the CA needs to validate the SII passed by the RA. - The CA can treat the SIM as an additional name form in the "subjectAltName" extension with no special processing. - Alice cannot find another SII (SIIx), and a password (P), that will allow her to use her certificate to assert a false SII.
- 即使Alice选择了一个弱密码，Eve也有一个很大的工作系数来根据Alice的证书确定Alice的SIIa，如果Alice选择了一个好密码，则有一个很大的工作系数。-即使Eve能够确定SII，她也同样难以从任何其他百事可乐中找到任何其他SII值；也就是说，她无法预先计算任何东西来帮助她在其他证书中攻击PEPSIs，她从成功的攻击中学到的任何东西都无法帮助她进行任何其他攻击。-CA不学习Alice的SII，除非CA需要验证RA通过的SII。-CA可以将SIM作为“subjectAltName”扩展名中的附加姓名表单，无需特殊处理。-Alice找不到另一个SII（SIIx）和密码（P），这将允许她使用她的证书断言错误的SII。
In addition to the security properties stated above, we have the following usability requirements:
除上述安全属性外，我们还有以下可用性要求：
- When SIM and PEPSI are used, any custom processing occurs at the relying party. Alice can use commercial off-the-shelf software (e.g., a standard browser) without modification in conjunction with a certificate containing a SIM value.
- 使用SIM卡和百事可乐时，依赖方会进行任何定制处理。Alice可以使用商用现成软件（例如，标准浏览器），无需修改即可与包含SIM值的证书结合使用。
We define SIM as: R || PEPSI
where PEPSI = H(H( P || R || SIItype || SII))
We define SIM as: R || PEPSI
where PEPSI = H(H( P || R || SIItype || SII))
The following steps describe construction and use of SIM:
以下步骤描述SIM卡的构造和使用：
1. Alice picks a password P, and gives P, SIItype, and SII to the RA (via a secure channel). 2. The RA validates SIItype and SII; i.e., it determines that the SII value is correctly associated with the subject and the SIItype is correct. 3. The RA generates a random value R. 4. The RA generates the SIM = (R || PEPSI) where PEPSI = H(H(P || R || SIItype || SII)). 5. The RA sends the SIM to Alice by some out-of-band means and also passes it to the CA. 6. Alice sends a certRequest to CA. The CA generates Alice's certificate including the SIM as a form of otherName from the GeneralName structure in the subjectAltName extension. 7. Alice sends Bob her Cert, as well as P, SIItype, and SII. The latter values must be communicated via a secure communication channel, to preserve their confidentiality.
1. Alice选择密码P，并将P、SIItype和SII提供给RA（通过安全通道）。2.RA验证SIItype和SII；i、 例如，它确定SII值与对象正确关联，并且SII类型正确。3.RA生成一个随机值R.4。RA生成SIM=（R | PEPSI），其中PEPSI=H（H（P | R | SiitType | SII））。5.RA通过一些带外方式将SIM发送给Alice，并将其传递给CA.6。Alice向CA发送certRequest。CA根据subjectAltName扩展中的GeneralName结构生成Alice的证书，其中包括作为otherName形式的SIM卡。7.Alice向Bob发送她的证书以及P、SIItype和SII。后一种价值观必须通过安全的沟通渠道进行沟通，以保护其机密性。
8. Bob can compute PEPSI' = H(H(P || R || SIItype || SII)) and compare SIM' = R || PEPSI' to the SIM value in Alice's certificate, thereby verifying SII.
8. Bob可以计算PEPSI'=H（H（P | | R | | SIItype | | SII））并将SIM'=R | | PEPSI'与Alice证书中的SIM值进行比较，从而验证SII。
If Alice's SII value is not required by Bob (Bob already knows Alice's SII and does not require it), then steps 7 and 8 are as follows:
如果Bob不需要Alice的SII值（Bob已经知道Alice的SII并且不需要），那么步骤7和8如下：
7. Alice sends Bob her Cert and P. P must be sent via a secure communication channel, to preserve its confidentiality. 8. Bob can compute PEPSI' = H(H(P || R || SIItype || SII)) and compare SIM' = R || PEPSI' to the value in the SIM, thereby verifying SII.
7. Alice向Bob发送她的证书，P.P必须通过安全通信渠道发送，以保护其机密性。8.Bob可以计算PEPSI'=H（H（P | | R | | SIItype | | SII））并将SIM'=R | | PEPSI'与SIM中的值进行比较，从而验证SII。
If Alice wishes to prove she is the subject of an RA-validated identifier, without disclosing her identifier to Bob, then steps 7 and 8 are as follows:
如果Alice希望证明她是RA验证标识符的主体，而不向Bob透露她的标识符，则步骤7和8如下：
7. Alice sends the intermediate value H(P || R || SIItype || SII) and her certificate to Bob. 8. Bob can get R from the SIM in the certificate, then compute H (intermediate value) and compare it to the value in SIM, thereby verifying Alice's knowledge of P and SII.
7. Alice将中间值H（P | | R | | SIItype | | SII）和她的证书发送给Bob。8.Bob可以从证书中的SIM中获取R，然后计算H（中间值），并将其与SIM中的值进行比较，从而验证Alice对P和SII的了解。
Eve has to exhaustively search the H(P || R || SIItype || SII) space to find Alice's SII. This is a fairly hard problem even if Alice uses a poor password, because of the size of R (as specified later), and a really hard problem if Alice uses a fairly good password (see Section 8).
Eve必须彻底搜索H（P | | R | | | SIItype | | SII）空间才能找到Alice的SII。这是一个相当困难的问题，即使Alice使用了一个糟糕的密码，因为R的大小（稍后指定），如果Alice使用了一个相当好的密码，这也是一个非常困难的问题（参见第8节）。
Even if Eve finds Alice's P and SII, or constructs a massive dictionary of P and SII values, it does not help find any other SII values, because a new R is used for each PEPSI and SIM.
即使Eve找到了Alice的P和SII，或者构建了一个包含P和SII值的大字典，也无助于找到任何其他SII值，因为每个百事可乐和SIM卡都使用了一个新的R。
The user presents evidence that a particular SII has been assigned to him/her. The SIItype is an Object Identifier (OID) that defines the format and scope of the SII value. For example, in Korea, one SIItype is defined as follows:
用户提供证据，证明已将特定SII分配给他/她。SIItype是一个对象标识符（OID），用于定义SII值的格式和范围。例如，在韩国，一个SIItype定义如下：
-- KISA specific arc
id-KISA OBJECT IDENTIFIER ::=
{iso(1) member-body(2) korea(410) kisa(200004)}
-- KISA specific arc
id-KISA OBJECT IDENTIFIER ::=
{iso(1) member-body(2) korea(410) kisa(200004)}
-- KISA specific OIDs
id-npki OBJECT IDENTIFIER ::= {id-KISA 10}
id-attribute OBJECT IDENTIFIER ::= {id-npki 1}
id-kisa-identifyData OBJECT IDENTIFIER ::= {id-attribute 1}
id-VID OBJECT IDENTIFIER ::= {id-kisa-identifyData 10}
id-SII OBJECT IDENTIFIER ::= {id-VID 1}
-- KISA specific OIDs
id-npki OBJECT IDENTIFIER ::= {id-KISA 10}
id-attribute OBJECT IDENTIFIER ::= {id-npki 1}
id-kisa-identifyData OBJECT IDENTIFIER ::= {id-attribute 1}
id-VID OBJECT IDENTIFIER ::= {id-kisa-identifyData 10}
id-SII OBJECT IDENTIFIER ::= {id-VID 1}
For closed communities, the SIItype value may be assigned by the CA itself, but it is still recommended that the OID be registered.
对于封闭社区，SIItype值可以由CA本身分配，但仍然建议注册OID。
The user selects a password as one of the input values for computing the SIM. The strength of the password is critical to protection of the user's SII, in the following sense. If an attacker has a candidate SII value, and wants to determine whether the SIM value in a specific subject certificate, P is the only protection for the SIM. The user should be encouraged to select passwords that will be difficult to be guessed, and long enough to protect against brute force attacks.
用户选择密码作为计算SIM卡的输入值之一。从以下意义上讲，密码的强度对于保护用户的SII至关重要。如果攻击者具有候选SII值，并希望确定特定使用者证书中的SIM值是否正确，则P是对SIM的唯一保护。应鼓励用户选择难以猜测的密码，并且密码长度足以防止暴力攻击。
Implementations of this specification MUST permit a user to select passwords of up to 28 characters. RAs SHOULD implement password filter rules to prevent user selection of trivial passwords. See [FIPS 112] and [FIPS 180-1] for security criteria for passwords and an automated password generator algorithm that randomly creates simple pronounceable syllables as passwords.
本规范的实施必须允许用户选择最多28个字符的密码。RAs应该实现密码过滤规则，以防止用户选择琐碎的密码。请参见[FIPS 112]和[FIPS 180-1]，了解密码的安全标准和自动密码生成器算法，该算法随机创建简单可发音音节作为密码。
The RA generates a random number, R. A new R MUST be generated for each SIM. The length of R MUST be the same as the length of the output of the hash algorithm H. For example, if H is SHA-1, the random number MUST be 160 bits.
RA生成一个随机数R。必须为每个SIM生成一个新的R。R的长度必须与散列算法H的输出长度相同。例如，如果H是SHA-1，则随机数必须为160位。
A Random Number Generator (RNG) that meets the requirements defined in [FIPS 140-2] and its use is strongly recommended.
建议使用[RNG-2]随机数。
The SIM in the subjectAltName extension within a certificate identifies an entity, even if multiple subjectAltNames appear in a certificate. RAs MUST calculate the SIM value with the designated inputs according to the following algorithm:
证书中subjectAltName扩展名中的SIM标识实体，即使证书中出现多个subjectAltName。RAs必须根据以下算法计算指定输入的SIM值：
SIM = R || PEPSI
where PEPSI = H(H(P || R || SIItype || SII))
SIM = R || PEPSI
where PEPSI = H(H(P || R || SIItype || SII))
The SII is made known to an RA at user enrollment. Both SHA-1 and SHA-256 MUST be supported for generation and verification of PEPSI values. This specification does not preclude use of other one-way hash functions, but SHA-1 or SHA-256 SHOULD be used wherever interoperability is a concern.
SII在用户注册时告知RA。必须同时支持SHA-1和SHA-256以生成和验证百事价值。本规范不排除使用其他单向散列函数，但应在涉及互操作性的地方使用SHA-1或SHA-256。
Note that a secure communication channel MUST be used to pass P and SII passing from the end entity to the RA, to protect them from disclosure or modification.
注意，必须使用安全通信通道将P和SII从终端实体传递到RA，以保护它们不被披露或修改。
The syntax and the associated OID for SIM are also provided in the ASN.1 modules in Section 5.1. Also, Section 5.2 describes the syntax for PEPSI in the ASN.1 modules.
第5.1节的ASN.1模块中还提供了SIM的语法和相关OID。此外，第5.2节描述了ASN.1模块中百事可乐的语法。
It may be required that the CA (not just the RA) verifies SII before issuing a certificate. To meet this requirement, RA SHOULD encrypt the SIItype, SII, and SIM and send the result to the CA by a secure channel. The user SHOULD also encrypt the same values and send the result to the CA in his or her certificate request message. Then the CA compares these two results for verifying the user's SII.
可能需要CA（不仅仅是RA）在颁发证书之前验证SII。为满足此要求，RA应加密SIItype、SII和SIM，并通过安全通道将结果发送给CA。用户还应该加密相同的值，并在其证书请求消息中将结果发送给CA。然后CA比较这两个结果以验证用户的SII。
Where the results from RA and the user are the EPEPSI.
其中来自RA和用户的结果是EPSI。
EPEPSI = E(SIItype || SII || SIM)
EPPSI=E（SIItype | | SII | | SIM）
When the EPEPSI is used in a user certificate request, it is in regInfo of [RFC4211] and [RFC2986].
当EPSI用于用户证书请求时，它位于[RFC4211]和[RFC2986]的regInfo中。
Note: Specific encryption/decryption methods are not defined in this document. For transmission of the PEPSI value from a user to a CA, the certificate request protocol employed defines how encryption is performed. For transmission of this data between an RA and a CA, the details of how encryption is performed is a local matter.
注意：本文档中未定义特定的加密/解密方法。为了将PEPSI值从用户传输到CA，所采用的证书请求协议定义了如何执行加密。对于在RA和CA之间传输该数据，如何执行加密的细节是本地事务。
The syntax and the associated OID for EPEPSI is provided in the ASN.1 modules in Section 5.3.
第5.3节的ASN.1模块中提供了EPEPSI的语法和相关OID。
As described above, a certificate request message MAY contain the SIM. [RFC2986] and [RFC4211] are widely used message syntaxes for certificate requests.
如上所述，证书请求消息可以包含SIM。[RFC2986]和[RFC4211]是广泛用于证书请求的消息语法。
Basically, a PKCS#10 message consists of a distinguished name, a public key, and an optional set of attributes, collectively signed by
基本上，PKCS#10消息由一个可分辨名称、一个公钥和一组可选属性组成，这些属性由
the end entity. The SIM alternative name MUST be placed in the subjectAltName extension if this certificate request format is used. If a CA verifies SII before issuing the certificate, the value of SIM in the certification request MUST be conveyed in the EPEPSI form and provided by the subject.
最终实体。如果使用此证书请求格式，则SIM备用名称必须置于subjectAltName扩展名中。如果CA在颁发证书之前验证了SII，则认证请求中的SIM值必须在EPEPSI表格中传达，并由主体提供。
A CA that issues certificates containing the SIM includes the SIM as a form of otherName from the GeneralName structure in the "subjectAltName" extension.
颁发包含SIM卡的证书的CA将SIM卡作为其他名称的一种形式从“subjectAltName”扩展名中的GeneralName结构中包含。
In an environment where a CA verifies SII before issuing the certificate, a CA decrypts the EPEPSI values it receives from both the user and the RA, and compares them. It then validates that the SII value is correctly bound to the subject.
在CA在颁发证书之前验证SII的环境中，CA解密从用户和RA接收的EPEPSI值，并对它们进行比较。然后验证SII值是否正确绑定到主题。
SIItype, SII, SIM = D(EPEPSI)
SIItype，SII，SIM=D（EPSI）
This section specifies the syntax for the SIM name form included in the subjectAltName extension. The SIM is composed of the three fields: the hash algorithm identifier, the authority-chosen random value, and the value of the PEPSI itself.
本节指定subjectAltName扩展名中包含的SIM卡名称表单的语法。SIM卡由三个字段组成：散列算法标识符、权威选择的随机值和PEPSI本身的值。
id-pkix OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) }
id-pkix OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) }
id-on OBJECT IDENTIFIER ::= { id-pkix 8 }
id-on-SIM OBJECT IDENTIFIER ::= { id-on 6 }
id-on OBJECT IDENTIFIER ::= { id-pkix 8 }
id-on-SIM OBJECT IDENTIFIER ::= { id-on 6 }
SIM ::= SEQUENCE {
hashAlg AlgorithmIdentifier,
authorityRandom OCTET STRING, -- RA-chosen random number
-- used in computation of
-- pEPSI
pEPSI OCTET STRING -- hash of HashContent
-- with algorithm hashAlg
}
SIM ::= SEQUENCE {
hashAlg AlgorithmIdentifier,
authorityRandom OCTET STRING, -- RA-chosen random number
-- used in computation of
-- pEPSI
pEPSI OCTET STRING -- hash of HashContent
-- with algorithm hashAlg
}
This section specifies the syntax for the PEPSI. The PEPSI is generated by performing the same hash function twice. The PEPSI is generated over the ASN.1 structure HashContent. HashContent has four values: the user-selected password, the authority-chosen random number, the identifier type, and the identifier itself.
本节规定了百事可乐的语法。百事可乐是通过两次执行相同的哈希函数生成的。百事可乐是通过ASN.1结构内容生成的。HashContent有四个值：用户选择的密码、权威机构选择的随机数、标识符类型和标识符本身。
HashContent ::= SEQUENCE {
userPassword UTF8String,
-- user-supplied password
authorityRandom OCTET STRING,
-- RA-chosen random number
identifierType OBJECT IDENTIFIER, -- SIItype
identifier UTF8String -- SII
}
HashContent ::= SEQUENCE {
userPassword UTF8String,
-- user-supplied password
authorityRandom OCTET STRING,
-- RA-chosen random number
identifierType OBJECT IDENTIFIER, -- SIItype
identifier UTF8String -- SII
}
Before calculating a PEPSI, conforming implementations MUST process the userPassword with the six-step [LDAPBIS STRPREP] string preparation algorithm, with the following changes:
在计算PEPSI之前，一致性实施必须使用六步[LDAPBIS STRPREP]字符串准备算法处理用户密码，并进行以下更改：
* In step 2, Map, the mapping shall include processing of characters commonly mapped to nothing, as specified in Appendix B.1 of [RFC3454]. * Omit step 6, Insignificant Character Removal.
* 在步骤2中，映射应包括[RFC3454]附录B.1中规定的通常映射为空的字符的处理。*省略步骤6，删除不重要的字符。
This section describes the syntax for the Encrypted PEPSI. The Encrypted PEPSI has three fields: identifierType, identifier, and SIM.
本节介绍加密的PEPSI的语法。加密的百事可乐有三个字段：identifierType、identifier和SIM。
EncryptedPEPSI ::= SEQUENCE {
identifierType OBJECT IDENTIFIER, -- SIItype
identifier UTF8String, -- SII
sIM SIM -- Value of the SIM
}
EncryptedPEPSI ::= SEQUENCE {
identifierType OBJECT IDENTIFIER, -- SIItype
identifier UTF8String, -- SII
sIM SIM -- Value of the SIM
}
When it is used in a certificate request, the OID in 'regInfo' of [RFC4211] and [RFC2986] is as follows:
在证书请求中使用时，[RFC4211]和[RFC2986]的“regInfo”中的OID如下所示：
id-regEPEPSI OBJECT IDENTIFIER ::= { id-pkip 3 }
id-regEPEPSI OBJECT IDENTIFIER ::= { id-pkip 3 }
Depending on different security environments, there are three possible use cases with SIM.
根据不同的安全环境，SIM卡有三种可能的使用情况。
1. When a relying party does not have any information about the certificate user. 2. When a relying party already knows the SII of the certificate user. 3. When the certificate user does not want to disclose his SII.
1. 当依赖方没有关于证书用户的任何信息时。2.当依赖方已经知道证书用户的SII时。3.当证书用户不想披露其SII时。
For the use case 1, the SII and a user-chosen password P (which only the user knows) must be sent to a relying party via a secure communication channel; the certificate including the SIM also must be transmitted. The relying party acquires R from the certificate. The relying party can verify that the SII was validated by the CA (or RA) and is associated with the entity that presented the password and certificate. In this case, the RP learns which SII is bound to the subject as a result of the procedure.
对于用例1，必须通过安全通信信道将SII和用户选择的密码P（只有用户知道）发送给依赖方；还必须传输包括SIM卡在内的证书。依赖方从证书中获取R。依赖方可以验证SII是否已由CA（或RA）验证，并与提供密码和证书的实体关联。在这种情况下，RP通过程序了解哪个SII绑定到受试者。
In case 2, a certificate user transmits only the password, P, and the certificate. The rest of the detailed procedure is the same as case 1, but here the relying party supplies the SII value, based on its external knowledge of that value. The purpose in this case is to enable the RP to verify that the subject is bound to the SII, presumably because the RP identifies the subject based on this SII.
在案例2中，证书用户仅传输密码P和证书。详细程序的其余部分与案例1相同，但此处依赖方根据其对该值的外部了解提供SII值。这种情况下的目的是使RP能够验证受试者是否绑定到SII，可能是因为RP基于此SII识别受试者。
In the last case, the certificate user does not want to disclose his or her SII because of privacy concerns. Here the only information sent by a certificate subject is the intermediate value of the PEPSI, H(R || P || SIItype || SII). This value MUST be transmitted via a secure channel, to preserve its confidentiality. Upon receiving this value, the relying party applies the hash function to the intermediate PEPSI value sent by the user, and matches it against the SIM value in the user's certificate. The relying party does not learn the user's SII value as a result of this processing, but the relying party can verify the fact that the user knows the right SII and password. This gives the relying party more confidence that the user is the certificate subject. Note that this form of user identity verification is NOT to be used in lieu of standard certificate validation procedures, but rather in addition to such procedures.
在最后一种情况下，出于隐私考虑，证书用户不想披露他或她的SII。这里，证书主体发送的唯一信息是PEPSI的中间值H（R | | P | | SIItype | | SII）。此值必须通过安全通道传输，以保护其机密性。一旦收到该值，依赖方将哈希函数应用于用户发送的中间PEPSI值，并将其与用户证书中的SIM值进行匹配。依赖方不会通过此处理了解用户的SII值，但依赖方可以验证用户知道正确的SII和密码这一事实。这使依赖方更加相信用户是证书的主体。请注意，这种形式的用户身份验证不能代替标准证书验证程序，而是作为此类程序的补充。
The SIM value is stored as an otherName of a subject alternative name; however, there are no constraints that can be placed on this form of the name.
作为对象名的替代值存储的对象名；但是，对于这种形式的名称并没有任何约束。
Confidentiality for a SIM value is created by the iterated hashing of the R, P, and SII values. A SIM value depends on two properties of a hash function: the fact that it cannot be inverted and the fact that collisions (especially with formatted data) are rare. The current attacks by [WANG] are not applicable to SIM values since the end entity supplying the SII and SIItype values does not supply all of the data being hashed; i.e., the RA provides the R value.
SIM值的机密性是通过R、P和SII值的迭代散列创建的。SIM值取决于散列函数的两个属性：不能反转的事实和冲突（尤其是格式化数据）很少的事实。[WANG]当前的攻击不适用于SIM值，因为提供SII和SIItype值的终端实体并不提供所有被散列的数据；i、 例如，RA提供R值。
In addition, a fairly good password is needed to protect against guessing attacks on SIMs. Due to the short length of many SIIs, it is possible that an attacker may be able to guess it with partial information about gender, age, and date of birth. SIItype values are very limited. Therefore, it is important for users to select a fairly good password to prevent an attacker from determining whether a guessed SII is accurate.
此外，还需要一个相当好的密码来防止对SIM卡的猜测攻击。由于许多SII的长度较短，攻击者有可能利用有关性别、年龄和出生日期的部分信息来猜测SII。SIItype值非常有限。因此，用户必须选择一个相当好的密码，以防止攻击者确定猜测的SII是否准确。
This protocol assumes that Bob is a trustworthy relying party who will not reuse the Alice's information. Otherwise, Bob could "impersonate" Alice if only knowledge of P and SII were used to verify a subject's claimed identity. Thus, this protocol MUST be used only with the protocols that make use of digital signatures generated using the subject's private key.
该协议假设Bob是一个可靠的依赖方，不会重用Alice的信息。否则，如果只使用P和SII的知识来验证受试者声称的身份，Bob就可以“模拟”Alice。因此，该协议必须仅与使用主体私钥生成的数字签名的协议一起使用。
Digital signatures are used by a message sender to demonstrate knowledge of the private key corresponding to the public key in a certificate, and thus to authenticate and bind his or her identity to a signed message. However, managing a private key is vulnerable under certain circumstances. It is not fully guaranteed that the claimed private key is bound to the subject of a certificate. So, the SIM can enhance verification of user identity.
消息发送者使用数字签名来证明对证书中公钥对应的私钥的了解，从而对其身份进行身份验证并将其绑定到签名消息。但是，在某些情况下，管理私钥容易受到攻击。不能完全保证声明的私钥绑定到证书的主题。因此，SIM卡可以增强对用户身份的验证。
Whenever a certificate needs to be updated, a new R SHOULD be generated and the SIM SHOULD be recomputed. Repeating the value of the SIM from a previous certificate permits an attacker to identify certificates associated with the same individual, which may be undesirable for personal privacy purposes.
每当需要更新证书时，应生成新的R并重新计算SIM。重复以前证书中的SIM值可使攻击者识别与同一个人相关的证书，这可能不利于个人隐私。
Jim Schaad (Soaring Hawk Consulting), Seungjoo Kim, Jaeho Yoon, Baehyo Park (KISA), Bill Burr, Morrie Dworkin (NIST), and the Internet Security Technology Forum (ISTF) have significantly contributed to work on the SIM and PEPSI concept and identified a potential security attack. Also their comments on the set of desirable properties for the PEPSI and enhancements to the PEPSI were most illumination. Also, thanks to Russell Housley, Stephen Kent, and Denis Pinkas for their contributions to this document.
Jim Schaad（翱翔鹰咨询公司）、Seungjoo Kim、Jaeho Yoon、Baehyo Park（KISA）、Bill Burr、Morrie Dworkin（NIST）和互联网安全技术论坛（ISTF）对SIM和百事概念的研究做出了重大贡献，并发现了潜在的安全攻击。此外，他们对百事可乐的一系列理想特性和百事可乐的增强功能的评论也是最具启发性的。同时，感谢Russell Housley、Stephen Kent和Denis Pinkas对本文件的贡献。
In the future, IANA may be asked to establish a registry of object identifiers to promote interoperability in the specification of SII types.
将来，IANA可能会被要求建立一个对象标识符注册中心，以促进SII类型规范中的互操作性。
[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月。
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification Request Syntax Specification Version 1.7", RFC 2986, November 2000.
[RFC2986]Nystrom，M.和B.Kaliski，“PKCS#10：认证请求语法规范版本1.7”，RFC 2986，2000年11月。
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
[RFC3454]Hoffman，P.和M.Blanchet，“国际化弦的准备（“stringprep”）”，RFC 3454，2002年12月。
[RFC4043] Pinkas, D. and T. Gindin, "Internet X.509 Public Key Infrastructure Permanent Identifier", RFC 4043, May 2005.
[RFC4043]Pinkas，D.和T.Gindin，“互联网X.509公钥基础设施永久标识符”，RFC 4043，2005年5月。
[RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)", RFC 4211, September 2005.
[RFC4211]Schaad，J.“Internet X.509公钥基础设施证书请求消息格式（CRMF）”，RFC 42112005年9月。
[LDAPBIS STRPREP] Zeilenga, K., "LDAP: Internationalized String Preparation", Work in Progress.
[LDAPBIS STRPREP]Zeilenga，K.，“LDAP：国际化字符串准备”，正在进行的工作。
[FIPS 112] Fedreal Information Processing Standards Publication (FIPS PUB) 112, "Password Usage", 30 May 1985.
[FIPS 112]联邦信息处理标准出版物（FIPS PUB）112，“密码使用”，1985年5月30日。
[FIPS 180-1] Federal Information Processing Standards Publication (FIPS PUB) 180-1, "Secure Hash Standard", 17 April 1995.
[FIPS 180-1]联邦信息处理标准出版物（FIPS PUB）180-1，“安全哈希标准”，1995年4月17日。
[FIPS 140-2] Federal Information Processing Standards Publication (FIPS PUB) 140-2, "Security Requirements for Cryptographic Modules", 25 May 2001.
[FIPS 140-2]联邦信息处理标准出版物（FIPS PUB）140-2，“加密模块的安全要求”，2001年5月25日。
[WANG] Xiaoyun Wang, Yiqun Lisa Yin, and Hongbo Yu,
"Finding Collisions in the Full SHA-1", Crypto'05.
<http://www.infosec.sdu.edu.cn/paper/sha1-crypto-
auth-new-2-yao.pdf>
[WANG] Xiaoyun Wang, Yiqun Lisa Yin, and Hongbo Yu,
"Finding Collisions in the Full SHA-1", Crypto'05.
<http://www.infosec.sdu.edu.cn/paper/sha1-crypto-
auth-new-2-yao.pdf>
Authors' Addresses
作者地址
Jongwook Park Korea Information Security Agency 78, Garak-Dong, Songpa-Gu, Seoul, 138-803 REPUBLIC OF KOREA
Jongwook Park韩国信息安全局78号，韩国首尔松帕谷Garak Dong，138-803
Phone: 2-405-5432 EMail: khopri@kisa.or.kr
电话：2-405-5432电子邮件：khopri@kisa.or.kr
Jaeil Lee 78, Garak-Dong, Songpa-Gu, Seoul, 138-803 REPUBLIC OF KOREA Korea Information Security Agency
Jaeil Lee 78，韩国信息安全局，首尔松帕谷Garak Dong，138-803
Phone: 2-405-5300 EMail: jilee@kisa.or.kr
电话：2-405-5300电子邮件：jilee@kisa.or.kr
Hongsub Lee Korea Information Security Agency 78, Garak-Dong, Songpa-Gu, Seoul, 138-803 REPUBLIC OF KOREA
韩国汉城松帕谷Garak Dong Hongsub Lee韩国信息安全局78号，邮编：138-803
Phone: 2-405-5100 EMail: hslee@kisa.or.kr
电话：2-405-5100电子邮件：hslee@kisa.or.kr
Sangjoon Park BCQRE Co.,Ltd Yuil Bldg. Dogok-dong 411-14, Kangnam-ku, Seoul, 135-270 REPUBLIC OF KOREA
韩国汉城康南库多格洞Yuil大厦411-14号，三重公园BCQRE有限公司，韩国汉城135-270
EMail: sjpark@bcqre.com
EMail: sjpark@bcqre.com
Tim Polk National Institute of Standards and Technology 100 Bureau Drive, MS 8930 Gaithersburg, MD 20899
美国马里兰州盖瑟斯堡市局道100号蒂姆·波尔克国家标准与技术研究所，邮编：20899，邮编：8930
EMail: tim.polk@nist.gov
EMail: tim.polk@nist.gov
Appendix A. "Compilable" ASN.1 Module, 1988 Syntax
附录A“可编译”ASN.1模块，1988年语法
PKIXSIM {iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-sim2005(38) }
PKIXSIM {iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-sim2005(38) }
DEFINITIONS EXPLICIT TAGS ::=
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
开始
-- EXPORTS ALL
--全部出口
IMPORTS
进口
AlgorithmIdentifier, AttributeTypeAndValue FROM PKIX1Explicit88
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit(18)}
AlgorithmIdentifier, AttributeTypeAndValue FROM PKIX1Explicit88
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit(18)}
-- SIM
--模拟
-- SIM certificate OID
--SIM证书ID
id-pkix OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) }
id-pkix OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) }
id-on OBJECT IDENTIFIER ::= { id-pkix 8 }
id-on-SIM OBJECT IDENTIFIER ::= { id-on 6 }
id-on OBJECT IDENTIFIER ::= { id-pkix 8 }
id-on-SIM OBJECT IDENTIFIER ::= { id-on 6 }
-- Certificate Syntax
--证书语法
SIM ::= SEQUENCE {
hashAlg AlgorithmIdentifier,
authorityRandom OCTET STRING, -- RA-chosen random number
-- used in computation of
-- pEPSI
pEPSI OCTET STRING -- hash of HashContent
-- with algorithm hashAlg
}
SIM ::= SEQUENCE {
hashAlg AlgorithmIdentifier,
authorityRandom OCTET STRING, -- RA-chosen random number
-- used in computation of
-- pEPSI
pEPSI OCTET STRING -- hash of HashContent
-- with algorithm hashAlg
}
-- PEPSI
--百事可乐
UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
-- The content of this type conforms to RFC 2279
UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
-- The content of this type conforms to RFC 2279
HashContent ::= SEQUENCE {
userPassword UTF8String,
-- user-supplied password
authorityRandom OCTET STRING,
HashContent ::= SEQUENCE {
userPassword UTF8String,
-- user-supplied password
authorityRandom OCTET STRING,
-- RA-chosen random number identifierType OBJECT IDENTIFIER, -- SIItype identifier UTF8String -- SII }
--RA所选随机数标识符类型对象标识符，--SIItype标识符UTF8String--SII}
-- Encrypted PEPSI
--加密百事可乐
-- OID for encapsulated content type
--用于封装内容类型的OID
id-regEPEPSI OBJECT IDENTIFIER ::= { id-pkip 3 }
id-regEPEPSI OBJECT IDENTIFIER ::= { id-pkip 3 }
EncryptedPEPSI ::= SEQUENCE {
identifierType OBJECT IDENTIFIER, -- SIItype
identifier UTF8String, -- SII
sIM SIM -- Value of the SIM
}
EncryptedPEPSI ::= SEQUENCE {
identifierType OBJECT IDENTIFIER, -- SIItype
identifier UTF8String, -- SII
sIM SIM -- Value of the SIM
}
END
终止
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）提供。