RFC3279 日本語訳

3279 Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL)Profile. L. Bassham, W. Polk, R. Housley. April 2002. (Format: TXT=53833 bytes) (Updated by RFC4055, RFC4491) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                            W. Polk
Request for Comments: 3279                                          NIST
Obsoletes: 2528                                               R. Housley
Category: Standards Track                               RSA Laboratories
                                                              L. Bassham
                                                                    NIST
                                                              April 2002

Network Working Group W. Polk Request for Comments: 3279 NIST Obsoletes: 2528 R. Housley Category: Standards Track RSA Laboratories L. Bassham NIST April 2002

                   Algorithms and Identifiers for the
                Internet X.509 Public Key Infrastructure
       Certificate and Certificate Revocation List (CRL) Profile

Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile

Status of this Memo

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.

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.

Copyright Notice

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Copyright (C) The Internet Society (2002). All Rights Reserved.

Abstract

Abstract

   This document specifies algorithm identifiers and ASN.1 encoding
   formats for digital signatures and subject public keys used in the
   Internet X.509 Public Key Infrastructure (PKI).  Digital signatures
   are used to sign certificates and certificate revocation list (CRLs).
   Certificates include the public key of the named subject.

This document specifies algorithm identifiers and ASN.1 encoding formats for digital signatures and subject public keys used in the Internet X.509 Public Key Infrastructure (PKI). Digital signatures are used to sign certificates and certificate revocation list (CRLs). Certificates include the public key of the named subject.

Table of Contents

Table of Contents

   1  Introduction  . . . . . . . . . . . . . . . . . . . . . .   2
   2  Algorithm Support . . . . . . . . . . . . . . . . . . . .   3
   2.1  One-Way Hash Functions  . . . . . . . . . . . . . . . .   3
   2.1.1  MD2 One-Way Hash Functions  . . . . . . . . . . . . .   3
   2.1.2  MD5 One-Way Hash Functions  . . . . . . . . . . . . .   4
   2.1.3  SHA-1 One-Way Hash Functions  . . . . . . . . . . . .   4
   2.2  Signature Algorithms  . . . . . . . . . . . . . . . . .   4
   2.2.1  RSA Signature Algorithm . . . . . . . . . . . . . . .   5
   2.2.2  DSA Signature Algorithm . . . . . . . . . . . . . . .   6
   2.2.3  Elliptic Curve Digital Signature Algorithm  . . . . .   7
   2.3  Subject Public Key Algorithms . . . . . . . . . . . . .   7
   2.3.1  RSA Keys  . . . . . . . . . . . . . . . . . . . . . .   8
   2.3.2  DSA Signature Keys  . . . . . . . . . . . . . . . . .   9
   2.3.3  Diffie-Hellman Key Exchange Keys  . . . . . . . . . .  10

1 Introduction . . . . . . . . . . . . . . . . . . . . . . 2 2 Algorithm Support . . . . . . . . . . . . . . . . . . . . 3 2.1 One-Way Hash Functions . . . . . . . . . . . . . . . . 3 2.1.1 MD2 One-Way Hash Functions . . . . . . . . . . . . . 3 2.1.2 MD5 One-Way Hash Functions . . . . . . . . . . . . . 4 2.1.3 SHA-1 One-Way Hash Functions . . . . . . . . . . . . 4 2.2 Signature Algorithms . . . . . . . . . . . . . . . . . 4 2.2.1 RSA Signature Algorithm . . . . . . . . . . . . . . . 5 2.2.2 DSA Signature Algorithm . . . . . . . . . . . . . . . 6 2.2.3 Elliptic Curve Digital Signature Algorithm . . . . . 7 2.3 Subject Public Key Algorithms . . . . . . . . . . . . . 7 2.3.1 RSA Keys . . . . . . . . . . . . . . . . . . . . . . 8 2.3.2 DSA Signature Keys . . . . . . . . . . . . . . . . . 9 2.3.3 Diffie-Hellman Key Exchange Keys . . . . . . . . . . 10

Polk, et al.                Standards Track                     [Page 1]

RFC 3279               Algorithms and Identifiers             April 2002

Polk, et al. Standards Track [Page 1] RFC 3279 Algorithms and Identifiers April 2002

   2.3.4  KEA Public Keys . . . . . . . . . . . . . . . . . . .  11
   2.3.5  ECDSA and ECDH Public Keys  . . . . . . . . . . . . .  13
   3  ASN.1 Module  . . . . . . . . . . . . . . . . . . . . . .  18
   4  References  . . . . . . . . . . . . . . . . . . . . . . .  24
   5  Security Considerations . . . . . . . . . . . . . . . . .  25
   6  Intellectual Property Rights  . . . . . . . . . . . . . .  26
   7  Author Addresses  . . . . . . . . . . . . . . . . . . . .  26
   8  Full Copyright Statement  . . . . . . . . . . . . . . . .  27

2.3.4 KEA Public Keys . . . . . . . . . . . . . . . . . . . 11 2.3.5 ECDSA and ECDH Public Keys . . . . . . . . . . . . . 13 3 ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . 18 4 References . . . . . . . . . . . . . . . . . . . . . . . 24 5 Security Considerations . . . . . . . . . . . . . . . . . 25 6 Intellectual Property Rights . . . . . . . . . . . . . . 26 7 Author Addresses . . . . . . . . . . . . . . . . . . . . 26 8 Full Copyright Statement . . . . . . . . . . . . . . . . 27

1  Introduction

1 Introduction

   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 [RFC 2119].

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 [RFC 2119].

   This document specifies algorithm identifiers and ASN.1 [X.660]
   encoding formats for digital signatures and subject public keys used
   in the Internet X.509 Public Key Infrastructure (PKI).  This
   specification supplements [RFC 3280], "Internet X.509 Public Key
   Infrastructure:  Certificate and Certificate Revocation List (CRL)
   Profile."  Implementations of this specification MUST also conform to
   RFC 3280.

This document specifies algorithm identifiers and ASN.1 [X.660] encoding formats for digital signatures and subject public keys used in the Internet X.509 Public Key Infrastructure (PKI). This specification supplements [RFC 3280], "Internet X.509 Public Key Infrastructure: Certificate and Certificate Revocation List (CRL) Profile." Implementations of this specification MUST also conform to RFC 3280.

   This specification defines the contents of the signatureAlgorithm,
   signatureValue, signature, and subjectPublicKeyInfo fields within
   Internet X.509 certificates and CRLs.

This specification defines the contents of the signatureAlgorithm, signatureValue, signature, and subjectPublicKeyInfo fields within Internet X.509 certificates and CRLs.

   This document identifies one-way hash functions for use in the
   generation of digital signatures.  These algorithms are used in
   conjunction with digital signature algorithms.

This document identifies one-way hash functions for use in the generation of digital signatures. These algorithms are used in conjunction with digital signature algorithms.

   This specification describes the encoding of digital signatures
   generated with the following cryptographic algorithms:

This specification describes the encoding of digital signatures generated with the following cryptographic algorithms:

      * Rivest-Shamir-Adelman (RSA);
      * Digital Signature Algorithm (DSA); and
      * Elliptic Curve Digital Signature Algorithm (ECDSA).

* Rivest-Shamir-Adelman (RSA); * Digital Signature Algorithm (DSA); and * Elliptic Curve Digital Signature Algorithm (ECDSA).

   This document specifies the contents of the subjectPublicKeyInfo
   field in Internet X.509 certificates.  For each algorithm, the
   appropriate alternatives for the the keyUsage extension are provided.
   This specification describes encoding formats for public keys used
   with the following cryptographic algorithms:

This document specifies the contents of the subjectPublicKeyInfo field in Internet X.509 certificates. For each algorithm, the appropriate alternatives for the the keyUsage extension are provided. This specification describes encoding formats for public keys used with the following cryptographic algorithms:

      * Rivest-Shamir-Adelman (RSA);
      * Digital Signature Algorithm (DSA);
      * Diffie-Hellman (DH);
      * Key Encryption Algorithm (KEA);

* Rivest-Shamir-Adelman (RSA); * Digital Signature Algorithm (DSA); * Diffie-Hellman (DH); * Key Encryption Algorithm (KEA);

Polk, et al.                Standards Track                     [Page 2]

RFC 3279               Algorithms and Identifiers             April 2002

Polk, et al. Standards Track [Page 2] RFC 3279 Algorithms and Identifiers April 2002

      * Elliptic Curve Digital Signature Algorithm (ECDSA); and
      * Elliptic Curve Diffie-Hellman (ECDH).

* Elliptic Curve Digital Signature Algorithm (ECDSA); and * Elliptic Curve Diffie-Hellman (ECDH).

2  Algorithm Support

2 Algorithm Support

   This section describes cryptographic algorithms which may be used
   with the Internet X.509 certificate and CRL profile [RFC 3280].  This
   section describes one-way hash functions and digital signature
   algorithms which may be used to sign certificates and CRLs, and
   identifies object identifiers (OIDs) for public keys contained in a
   certificate.

This section describes cryptographic algorithms which may be used with the Internet X.509 certificate and CRL profile [RFC 3280]. This section describes one-way hash functions and digital signature algorithms which may be used to sign certificates and CRLs, and identifies object identifiers (OIDs) for public keys contained in a certificate.

   Conforming CAs and applications MUST, at a minimum, support digital
   signatures and public keys for one of the specified algorithms.  When
   using any of the algorithms identified in this specification,
   conforming CAs and applications MUST support them as described.

Conforming CAs and applications MUST, at a minimum, support digital signatures and public keys for one of the specified algorithms. When using any of the algorithms identified in this specification, conforming CAs and applications MUST support them as described.

2.1  One-way Hash Functions

2.1 One-way Hash Functions

   This section identifies one-way hash functions for use in the
   Internet X.509 PKI.  One-way hash functions are also called message
   digest algorithms.  SHA-1 is the preferred one-way hash function for
   the Internet X.509 PKI.  However, PEM uses MD2 for certificates [RFC
   1422] [RFC 1423] and MD5 is used in other legacy applications.  For
   these reasons, MD2 and MD5 are included in this profile.  The data
   that is hashed for certificate and CRL signing is fully described in
   [RFC 3280].

This section identifies one-way hash functions for use in the Internet X.509 PKI. One-way hash functions are also called message digest algorithms. SHA-1 is the preferred one-way hash function for the Internet X.509 PKI. However, PEM uses MD2 for certificates [RFC 1422] [RFC 1423] and MD5 is used in other legacy applications. For these reasons, MD2 and MD5 are included in this profile. The data that is hashed for certificate and CRL signing is fully described in [RFC 3280].

2.1.1  MD2 One-way Hash Function

2.1.1 MD2 One-way Hash Function

   MD2 was developed by Ron Rivest for RSA Security.  RSA Security has
   recently placed the MD2 algorithm in the public domain.  Previously,
   RSA Data Security had granted license for use of MD2 for non-
   commercial Internet Privacy-Enhanced Mail (PEM).  MD2 may continue to
   be used with PEM certificates, but SHA-1 is preferred.  MD2 produces
   a 128-bit "hash" of the input.  MD2 is fully described in [RFC 1319].

MD2 was developed by Ron Rivest for RSA Security. RSA Security has recently placed the MD2 algorithm in the public domain. Previously, RSA Data Security had granted license for use of MD2 for non- commercial Internet Privacy-Enhanced Mail (PEM). MD2 may continue to be used with PEM certificates, but SHA-1 is preferred. MD2 produces a 128-bit "hash" of the input. MD2 is fully described in [RFC 1319].

   At the Selected Areas in Cryptography '95 conference in May 1995,
   Rogier and Chauvaud presented an attack on MD2 that can nearly find
   collisions [RC95].  Collisions occur when one can find two different
   messages that generate the same message digest.  A checksum operation
   in MD2 is the only remaining obstacle to the success of the attack.
   For this reason, the use of MD2 for new applications is discouraged.
   It is still reasonable to use MD2 to verify existing signatures, as
   the ability to find collisions in MD2 does not enable an attacker to
   find new messages having a previously computed hash value.

At the Selected Areas in Cryptography '95 conference in May 1995, Rogier and Chauvaud presented an attack on MD2 that can nearly find collisions [RC95]. Collisions occur when one can find two different messages that generate the same message digest. A checksum operation in MD2 is the only remaining obstacle to the success of the attack. For this reason, the use of MD2 for new applications is discouraged. It is still reasonable to use MD2 to verify existing signatures, as the ability to find collisions in MD2 does not enable an attacker to find new messages having a previously computed hash value.

Polk, et al.                Standards Track                     [Page 3]

RFC 3279               Algorithms and Identifiers             April 2002

Polk, et al. Standards Track [Page 3] RFC 3279 Algorithms and Identifiers April 2002

2.1.2  MD5 One-way Hash Function

2.1.2 MD5 One-way Hash Function

   MD5 was developed by Ron Rivest for RSA Security.  RSA Security has
   placed the MD5 algorithm in the public domain.  MD5 produces a 128-
   bit "hash" of the input.  MD5 is fully described in [RFC 1321].

MD5 was developed by Ron Rivest for RSA Security. RSA Security has placed the MD5 algorithm in the public domain. MD5 produces a 128- bit "hash" of the input. MD5 is fully described in [RFC 1321].

   Den Boer and Bosselaers [DB94] have found pseudo-collisions for MD5,
   but there are no other known cryptanalytic results.  The use of MD5
   for new applications is discouraged.  It is still reasonable to use
   MD5 to verify existing signatures.

Den Boer and Bosselaers [DB94] have found pseudo-collisions for MD5, but there are no other known cryptanalytic results. The use of MD5 for new applications is discouraged. It is still reasonable to use MD5 to verify existing signatures.

2.1.3  SHA-1 One-way Hash Function

2.1.3 SHA-1 One-way Hash Function

   SHA-1 was developed by the U.S. Government.  SHA-1 produces a 160-bit
   "hash" of the input.  SHA-1 is fully described in [FIPS 180-1].  RFC
   3174 [RFC 3174] also describes SHA-1, and it provides an
   implementation of the algorithm.

SHA-1 was developed by the U.S. Government. SHA-1 produces a 160-bit "hash" of the input. SHA-1 is fully described in [FIPS 180-1]. RFC 3174 [RFC 3174] also describes SHA-1, and it provides an implementation of the algorithm.

2.2  Signature Algorithms

2.2 Signature Algorithms

   Certificates and CRLs conforming to [RFC 3280] may be signed with any
   public key signature algorithm.  The certificate or CRL indicates the
   algorithm through an algorithm identifier which appears in the
   signatureAlgorithm field within the Certificate or CertificateList.
   This algorithm identifier is an OID and has optionally associated
   parameters.  This section identifies algorithm identifiers and
   parameters that MUST be used in the signatureAlgorithm field in a
   Certificate or CertificateList.

Certificates and CRLs conforming to [RFC 3280] may be signed with any public key signature algorithm. The certificate or CRL indicates the algorithm through an algorithm identifier which appears in the signatureAlgorithm field within the Certificate or CertificateList. This algorithm identifier is an OID and has optionally associated parameters. This section identifies algorithm identifiers and parameters that MUST be used in the signatureAlgorithm field in a Certificate or CertificateList.

   Signature algorithms are always used in conjunction with a one-way
   hash function.

Signature algorithms are always used in conjunction with a one-way hash function.

   This section identifies OIDS for RSA, DSA, and ECDSA.  The contents
   of the parameters component for each algorithm vary; details are
   provided for each algorithm.

This section identifies OIDS for RSA, DSA, and ECDSA. The contents of the parameters component for each algorithm vary; details are provided for each algorithm.

   The data to be signed (e.g., the one-way hash function output value)
   is formatted for the signature algorithm to be used.  Then, a private
   key operation (e.g., RSA encryption) is performed to generate the
   signature value.  This signature value is then ASN.1 encoded as a BIT
   STRING and included in the Certificate or CertificateList in the
   signature field.

The data to be signed (e.g., the one-way hash function output value) is formatted for the signature algorithm to be used. Then, a private key operation (e.g., RSA encryption) is performed to generate the signature value. This signature value is then ASN.1 encoded as a BIT STRING and included in the Certificate or CertificateList in the signature field.

Polk, et al.                Standards Track                     [Page 4]

RFC 3279               Algorithms and Identifiers             April 2002

Polk, et al. Standards Track [Page 4] RFC 3279 Algorithms and Identifiers April 2002

2.2.1  RSA Signature Algorithm

2.2.1 RSA Signature Algorithm

   The RSA algorithm is named for its inventors: Rivest, Shamir, and
   Adleman.  This profile includes three signature algorithms based on
   the RSA asymmetric encryption algorithm.  The signature algorithms
   combine RSA with either the MD2, MD5, or the SHA-1 one-way hash
   functions.

The RSA algorithm is named for its inventors: Rivest, Shamir, and Adleman. This profile includes three signature algorithms based on the RSA asymmetric encryption algorithm. The signature algorithms combine RSA with either the MD2, MD5, or the SHA-1 one-way hash functions.

   The signature algorithm with SHA-1 and the RSA encryption algorithm
   is implemented using the padding and encoding conventions described
   in PKCS #1 [RFC 2313].  The message digest is computed using the
   SHA-1 hash algorithm.

The signature algorithm with SHA-1 and the RSA encryption algorithm is implemented using the padding and encoding conventions described in PKCS #1 [RFC 2313]. The message digest is computed using the SHA-1 hash algorithm.

   The RSA signature algorithm, as specified in PKCS #1 [RFC 2313]
   includes a data encoding step.  In this step, the message digest and
   the OID for the one-way hash function used to compute the digest are
   combined.  When performing the data encoding step, the md2, md5, and
   id-sha1 OIDs MUST be used to specify the MD2, MD5, and SHA-1 one-way
   hash functions, respectively:

The RSA signature algorithm, as specified in PKCS #1 [RFC 2313] includes a data encoding step. In this step, the message digest and the OID for the one-way hash function used to compute the digest are combined. When performing the data encoding step, the md2, md5, and id-sha1 OIDs MUST be used to specify the MD2, MD5, and SHA-1 one-way hash functions, respectively:

      md2  OBJECT IDENTIFIER ::= {
           iso(1) member-body(2) US(840) rsadsi(113549)
           digestAlgorithm(2) 2 }

md2 OBJECT IDENTIFIER ::= { iso(1) member-body(2) US(840) rsadsi(113549) digestAlgorithm(2) 2 }

      md5  OBJECT IDENTIFIER ::= {
           iso(1) member-body(2) US(840) rsadsi(113549)
           digestAlgorithm(2) 5 }

md5 OBJECT IDENTIFIER ::= { iso(1) member-body(2) US(840) rsadsi(113549) digestAlgorithm(2) 5 }

      id-sha1  OBJECT IDENTIFIER ::= {
           iso(1) identified-organization(3) oiw(14) secsig(3)
           algorithms(2) 26 }

id-sha1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) oiw(14) secsig(3) algorithms(2) 26 }

   The signature algorithm with MD2 and the RSA encryption algorithm is
   defined in PKCS #1 [RFC 2313].  As defined in PKCS #1 [RFC 2313], the
   ASN.1 OID used to identify this signature algorithm is:

The signature algorithm with MD2 and the RSA encryption algorithm is defined in PKCS #1 [RFC 2313]. As defined in PKCS #1 [RFC 2313], the ASN.1 OID used to identify this signature algorithm is:

      md2WithRSAEncryption OBJECT IDENTIFIER  ::=  {
          iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
          pkcs-1(1) 2  }

md2WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 2 }

   The signature algorithm with MD5 and the RSA encryption algorithm is
   defined in PKCS #1 [RFC 2313].  As defined in PKCS #1 [RFC 2313], the
   ASN.1 OID used to identify this signature algorithm is:

The signature algorithm with MD5 and the RSA encryption algorithm is defined in PKCS #1 [RFC 2313]. As defined in PKCS #1 [RFC 2313], the ASN.1 OID used to identify this signature algorithm is:

      md5WithRSAEncryption OBJECT IDENTIFIER  ::=  {
          iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
          pkcs-1(1) 4  }

md5WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 4 }

Polk, et al.                Standards Track                     [Page 5]

RFC 3279               Algorithms and Identifiers             April 2002

Polk, et al. Standards Track [Page 5] RFC 3279 Algorithms and Identifiers April 2002

   The ASN.1 object identifier used to identify this signature algorithm
   is:

The ASN.1 object identifier used to identify this signature algorithm is:

      sha-1WithRSAEncryption OBJECT IDENTIFIER  ::=  {
          iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
          pkcs-1(1) 5  }

sha-1WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 }

   When any of these three OIDs appears within the ASN.1 type
   AlgorithmIdentifier, the parameters component of that type SHALL be
   the ASN.1 type NULL.

When any of these three OIDs appears within the ASN.1 type AlgorithmIdentifier, the parameters component of that type SHALL be the ASN.1 type NULL.

   The RSA signature generation process and the encoding of the result
   is described in detail in PKCS #1 [RFC 2313].

The RSA signature generation process and the encoding of the result is described in detail in PKCS #1 [RFC 2313].

2.2.2  DSA Signature Algorithm

2.2.2 DSA Signature Algorithm

   The Digital Signature Algorithm (DSA) is defined in the Digital
   Signature Standard (DSS).  DSA was developed by the U.S. Government,
   and DSA is used in conjunction with the SHA-1 one-way hash function.
   DSA is fully described in [FIPS 186].  The ASN.1 OID used to identify
   this signature algorithm is:

The Digital Signature Algorithm (DSA) is defined in the Digital Signature Standard (DSS). DSA was developed by the U.S. Government, and DSA is used in conjunction with the SHA-1 one-way hash function. DSA is fully described in [FIPS 186]. The ASN.1 OID used to identify this signature algorithm is:

      id-dsa-with-sha1 OBJECT IDENTIFIER ::=  {
           iso(1) member-body(2) us(840) x9-57 (10040)
           x9cm(4) 3 }

id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) x9-57 (10040) x9cm(4) 3 }

   When the id-dsa-with-sha1 algorithm identifier appears as the
   algorithm field in an AlgorithmIdentifier, the encoding SHALL omit
   the parameters field.  That is, the AlgorithmIdentifier SHALL be a
   SEQUENCE of one component: the OBJECT IDENTIFIER id-dsa-with-sha1.

When the id-dsa-with-sha1 algorithm identifier appears as the algorithm field in an AlgorithmIdentifier, the encoding SHALL omit the parameters field. That is, the AlgorithmIdentifier SHALL be a SEQUENCE of one component: the OBJECT IDENTIFIER id-dsa-with-sha1.

   The DSA parameters in the subjectPublicKeyInfo field of the
   certificate of the issuer SHALL apply to the verification of the
   signature.

The DSA parameters in the subjectPublicKeyInfo field of the certificate of the issuer SHALL apply to the verification of the signature.

   When signing, the DSA algorithm generates two values.  These values
   are commonly referred to as r and s.  To easily transfer these two
   values as one signature, they SHALL be ASN.1 encoded using the
   following ASN.1 structure:

When signing, the DSA algorithm generates two values. These values are commonly referred to as r and s. To easily transfer these two values as one signature, they SHALL be ASN.1 encoded using the following ASN.1 structure:

      Dss-Sig-Value  ::=  SEQUENCE  {
              r       INTEGER,
              s       INTEGER  }

Dss-Sig-Value ::= SEQUENCE { r INTEGER, s INTEGER }

Polk, et al.                Standards Track                     [Page 6]

RFC 3279               Algorithms and Identifiers             April 2002

Polk, et al. Standards Track [Page 6] RFC 3279 Algorithms and Identifiers April 2002

2.2.3 ECDSA Signature Algorithm

2.2.3 ECDSA Signature Algorithm

   The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in
   [X9.62].  The ASN.1 object identifiers used to identify ECDSA are
   defined in the following arc:

The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in [X9.62]. The ASN.1 object identifiers used to identify ECDSA are defined in the following arc:

      ansi-X9-62  OBJECT IDENTIFIER ::= {
           iso(1) member-body(2) us(840) 10045 }

ansi-X9-62 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 10045 }

      id-ecSigType OBJECT IDENTIFIER  ::=  {
           ansi-X9-62 signatures(4) }

id-ecSigType OBJECT IDENTIFIER ::= { ansi-X9-62 signatures(4) }

   ECDSA is used in conjunction with the SHA-1 one-way hash function.
   The ASN.1 object identifier used to identify ECDSA with SHA-1 is:

ECDSA is used in conjunction with the SHA-1 one-way hash function. The ASN.1 object identifier used to identify ECDSA with SHA-1 is:

      ecdsa-with-SHA1  OBJECT IDENTIFIER ::= {
           id-ecSigType 1 }

ecdsa-with-SHA1 OBJECT IDENTIFIER ::= { id-ecSigType 1 }

   When the ecdsa-with-SHA1 algorithm identifier appears as the
   algorithm field in an AlgorithmIdentifier, the encoding MUST omit the
   parameters field.  That is, the AlgorithmIdentifier SHALL be a
   SEQUENCE of one component: the OBJECT IDENTIFIER ecdsa-with-SHA1.

When the ecdsa-with-SHA1 algorithm identifier appears as the algorithm field in an AlgorithmIdentifier, the encoding MUST omit the parameters field. That is, the AlgorithmIdentifier SHALL be a SEQUENCE of one component: the OBJECT IDENTIFIER ecdsa-with-SHA1.

   The elliptic curve parameters in the subjectPublicKeyInfo field of
   the certificate of the issuer SHALL apply to the verification of the
   signature.

The elliptic curve parameters in the subjectPublicKeyInfo field of the certificate of the issuer SHALL apply to the verification of the signature.

   When signing, the ECDSA algorithm generates two values.  These values
   are commonly referred to as r and s.  To easily transfer these two
   values as one signature, they MUST be ASN.1 encoded using the
   following ASN.1 structure:

When signing, the ECDSA algorithm generates two values. These values are commonly referred to as r and s. To easily transfer these two values as one signature, they MUST be ASN.1 encoded using the following ASN.1 structure:

      Ecdsa-Sig-Value  ::=  SEQUENCE  {
           r     INTEGER,
           s     INTEGER  }

Ecdsa-Sig-Value ::= SEQUENCE { r INTEGER, s INTEGER }

2.3  Subject Public Key Algorithms

2.3 Subject Public Key Algorithms

   Certificates conforming to [RFC 3280] may convey a public key for any
   public key algorithm.  The certificate indicates the algorithm
   through an algorithm identifier.  This algorithm identifier is an OID
   and optionally associated parameters.

Certificates conforming to [RFC 3280] may convey a public key for any public key algorithm. The certificate indicates the algorithm through an algorithm identifier. This algorithm identifier is an OID and optionally associated parameters.

   This section identifies preferred OIDs and parameters for the RSA,
   DSA, Diffie-Hellman, KEA, ECDSA, and ECDH algorithms.  Conforming CAs
   MUST use the identified OIDs when issuing certificates containing

This section identifies preferred OIDs and parameters for the RSA, DSA, Diffie-Hellman, KEA, ECDSA, and ECDH algorithms. Conforming CAs MUST use the identified OIDs when issuing certificates containing

Polk, et al.                Standards Track                     [Page 7]

RFC 3279               Algorithms and Identifiers             April 2002

Polk, et al. Standards Track [Page 7] RFC 3279 Algorithms and Identifiers April 2002

   public keys for these algorithms.  Conforming applications supporting
   any of these algorithms MUST, at a minimum, recognize the OID
   identified in this section.

public keys for these algorithms. Conforming applications supporting any of these algorithms MUST, at a minimum, recognize the OID identified in this section.

2.3.1  RSA Keys

2.3.1 RSA Keys

   The OID rsaEncryption identifies RSA public keys.

The OID rsaEncryption identifies RSA public keys.

      pkcs-1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
                     rsadsi(113549) pkcs(1) 1 }

pkcs-1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 1 }

      rsaEncryption OBJECT IDENTIFIER ::=  { pkcs-1 1}

rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1}

   The rsaEncryption OID is intended to be used in the algorithm field
   of a value of type AlgorithmIdentifier.  The parameters field MUST
   have ASN.1 type NULL for this algorithm identifier.

The rsaEncryption OID is intended to be used in the algorithm field of a value of type AlgorithmIdentifier. The parameters field MUST have ASN.1 type NULL for this algorithm identifier.

   The RSA public key MUST be encoded using the ASN.1 type RSAPublicKey:

The RSA public key MUST be encoded using the ASN.1 type RSAPublicKey:

      RSAPublicKey ::= SEQUENCE {
         modulus            INTEGER,    -- n
         publicExponent     INTEGER  }  -- e

RSAPublicKey ::= SEQUENCE { modulus INTEGER, -- n publicExponent INTEGER } -- e

   where modulus is the modulus n, and publicExponent is the public
   exponent e.  The DER encoded RSAPublicKey is the value of the BIT
   STRING subjectPublicKey.

where modulus is the modulus n, and publicExponent is the public exponent e. The DER encoded RSAPublicKey is the value of the BIT STRING subjectPublicKey.

   This OID is used in public key certificates for both RSA signature
   keys and RSA encryption keys.  The intended application for the key
   MAY be indicated in the key usage field (see [RFC 3280]).  The use of
   a single key for both signature and encryption purposes is not
   recommended, but is not forbidden.

This OID is used in public key certificates for both RSA signature keys and RSA encryption keys. The intended application for the key MAY be indicated in the key usage field (see [RFC 3280]). The use of a single key for both signature and encryption purposes is not recommended, but is not forbidden.

   If the keyUsage extension is present in an end entity certificate
   which conveys an RSA public key, any combination of the following
   values MAY be present:

If the keyUsage extension is present in an end entity certificate which conveys an RSA public key, any combination of the following values MAY be present:

      digitalSignature;
      nonRepudiation;
      keyEncipherment; and
      dataEncipherment.

digitalSignature; nonRepudiation; keyEncipherment; and dataEncipherment.

   If the keyUsage extension is present in a CA or CRL issuer
   certificate which conveys an RSA public key, any combination of the
   following values MAY be present:

If the keyUsage extension is present in a CA or CRL issuer certificate which conveys an RSA public key, any combination of the following values MAY be present:

      digitalSignature;
      nonRepudiation;

digitalSignature; nonRepudiation;

Polk, et al.                Standards Track                     [Page 8]

RFC 3279               Algorithms and Identifiers             April 2002

Polk, et al. Standards Track [Page 8] RFC 3279 Algorithms and Identifiers April 2002

      keyEncipherment;
      dataEncipherment;
      keyCertSign; and
      cRLSign.

keyEncipherment; dataEncipherment; keyCertSign; and cRLSign.

   However, this specification RECOMMENDS that if keyCertSign or cRLSign
   is present, both keyEncipherment and dataEncipherment SHOULD NOT be
   present.

However, this specification RECOMMENDS that if keyCertSign or cRLSign is present, both keyEncipherment and dataEncipherment SHOULD NOT be present.

2.3.2  DSA Signature Keys

2.3.2 DSA Signature Keys

   The Digital Signature Algorithm (DSA) is defined in the Digital
   Signature Standard (DSS) [FIPS 186].  The DSA OID supported by this
   profile is:

The Digital Signature Algorithm (DSA) is defined in the Digital Signature Standard (DSS) [FIPS 186]. The DSA OID supported by this profile is:

      id-dsa OBJECT IDENTIFIER ::= {
           iso(1) member-body(2) us(840) x9-57(10040) x9cm(4) 1 }

id-dsa OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) x9-57(10040) x9cm(4) 1 }

   The id-dsa algorithm syntax includes optional domain parameters.
   These parameters are commonly referred to as p, q, and g.  When
   omitted, the parameters component MUST be omitted entirely.  That is,
   the AlgorithmIdentifier MUST be a SEQUENCE of one component: the
   OBJECT IDENTIFIER id-dsa.

The id-dsa algorithm syntax includes optional domain parameters. These parameters are commonly referred to as p, q, and g. When omitted, the parameters component MUST be omitted entirely. That is, the AlgorithmIdentifier MUST be a SEQUENCE of one component: the OBJECT IDENTIFIER id-dsa.

   If the DSA domain parameters are present in the subjectPublicKeyInfo
   AlgorithmIdentifier, the parameters are included using the following
   ASN.1 structure:

If the DSA domain parameters are present in the subjectPublicKeyInfo AlgorithmIdentifier, the parameters are included using the following ASN.1 structure:

      Dss-Parms  ::=  SEQUENCE  {
          p             INTEGER,
          q             INTEGER,
          g             INTEGER  }

Dss-Parms ::= SEQUENCE { p INTEGER, q INTEGER, g INTEGER }

   The AlgorithmIdentifier within subjectPublicKeyInfo is the only place
   within a certificate where the parameters may be used.  If the DSA
   algorithm parameters are omitted from the subjectPublicKeyInfo
   AlgorithmIdentifier and the CA signed the subject certificate using
   DSA, then the certificate issuer's DSA parameters apply to the
   subject's DSA key.  If the DSA domain parameters are omitted from the
   SubjectPublicKeyInfo AlgorithmIdentifier and the CA signed the
   subject certificate using a signature algorithm other than DSA, then
   the subject's DSA domain parameters are distributed by other means.
   If the subjectPublicKeyInfo AlgorithmIdentifier field omits the
   parameters component, the CA signed the subject with a signature
   algorithm other than DSA, and the subject's DSA parameters are not
   available through other means, then clients MUST reject the
   certificate.

The AlgorithmIdentifier within subjectPublicKeyInfo is the only place within a certificate where the parameters may be used. If the DSA algorithm parameters are omitted from the subjectPublicKeyInfo AlgorithmIdentifier and the CA signed the subject certificate using DSA, then the certificate issuer's DSA parameters apply to the subject's DSA key. If the DSA domain parameters are omitted from the SubjectPublicKeyInfo AlgorithmIdentifier and the CA signed the subject certificate using a signature algorithm other than DSA, then the subject's DSA domain parameters are distributed by other means. If the subjectPublicKeyInfo AlgorithmIdentifier field omits the parameters component, the CA signed the subject with a signature algorithm other than DSA, and the subject's DSA parameters are not available through other means, then clients MUST reject the certificate.

Polk, et al.                Standards Track                     [Page 9]

RFC 3279               Algorithms and Identifiers             April 2002

Polk, et al. Standards Track [Page 9] RFC 3279 Algorithms and Identifiers April 2002

   The DSA public key MUST be ASN.1 DER encoded as an INTEGER; this
   encoding shall be used as the contents (i.e., the value) of the
   subjectPublicKey component (a BIT STRING) of the SubjectPublicKeyInfo
   data element.

The DSA public key MUST be ASN.1 DER encoded as an INTEGER; this encoding shall be used as the contents (i.e., the value) of the subjectPublicKey component (a BIT STRING) of the SubjectPublicKeyInfo data element.

      DSAPublicKey ::= INTEGER -- public key, Y

DSAPublicKey ::= INTEGER -- public key, Y

   If the keyUsage extension is present in an end entity certificate
   which conveys a DSA public key, any combination of the following
   values MAY be present:

If the keyUsage extension is present in an end entity certificate which conveys a DSA public key, any combination of the following values MAY be present:

      digitalSignature;
      nonRepudiation;

digitalSignature; nonRepudiation;

   If the keyUsage extension is present in a CA or CRL issuer
   certificate which conveys a DSA public key, any combination of the
   following values MAY be present:

If the keyUsage extension is present in a CA or CRL issuer certificate which conveys a DSA public key, any combination of the following values MAY be present:

      digitalSignature;
      nonRepudiation;
      keyCertSign; and
      cRLSign.

digitalSignature; nonRepudiation; keyCertSign; and cRLSign.

2.3.3  Diffie-Hellman Key Exchange Keys

2.3.3 Diffie-Hellman Key Exchange Keys

   The Diffie-Hellman OID supported by this profile is defined in
   [X9.42].

The Diffie-Hellman OID supported by this profile is defined in [X9.42].

      dhpublicnumber OBJECT IDENTIFIER ::= { iso(1) member-body(2)
                us(840) ansi-x942(10046) number-type(2) 1 }

dhpublicnumber OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-x942(10046) number-type(2) 1 }

   The dhpublicnumber OID is intended to be used in the algorithm field
   of a value of type AlgorithmIdentifier.  The parameters field of that
   type, which has the algorithm-specific syntax ANY DEFINED BY
   algorithm, have the ASN.1 type DomainParameters for this algorithm.

The dhpublicnumber OID is intended to be used in the algorithm field of a value of type AlgorithmIdentifier. The parameters field of that type, which has the algorithm-specific syntax ANY DEFINED BY algorithm, have the ASN.1 type DomainParameters for this algorithm.

      DomainParameters ::= SEQUENCE {
            p       INTEGER, -- odd prime, p=jq +1
            g       INTEGER, -- generator, g
            q       INTEGER, -- factor of p-1
            j       INTEGER OPTIONAL, -- subgroup factor
            validationParms  ValidationParms OPTIONAL }

DomainParameters ::= SEQUENCE { p INTEGER, -- odd prime, p=jq +1 g INTEGER, -- generator, g q INTEGER, -- factor of p-1 j INTEGER OPTIONAL, -- subgroup factor validationParms ValidationParms OPTIONAL }

      ValidationParms ::= SEQUENCE {
            seed             BIT STRING,
            pgenCounter      INTEGER }

ValidationParms ::= SEQUENCE { seed BIT STRING, pgenCounter INTEGER }

Polk, et al.                Standards Track                    [Page 10]

RFC 3279               Algorithms and Identifiers             April 2002

Polk, et al. Standards Track [Page 10] RFC 3279 Algorithms and Identifiers April 2002

   The fields of type DomainParameters have the following meanings:

The fields of type DomainParameters have the following meanings:

      p identifies the prime p defining the Galois field;

p identifies the prime p defining the Galois field;

      g specifies the generator of the multiplicative subgroup of order
      g;

g specifies the generator of the multiplicative subgroup of order g;

      q specifies the prime factor of p-1;

q specifies the prime factor of p-1;

      j optionally specifies the value that satisfies the equation
      p=jq+1 to support the optional verification of group parameters;

j optionally specifies the value that satisfies the equation p=jq+1 to support the optional verification of group parameters;

      seed optionally specifies the bit string parameter used as the
      seed for the domain parameter generation process; and

seed optionally specifies the bit string parameter used as the seed for the domain parameter generation process; and

      pgenCounter optionally specifies the integer value output as part
      of the of the domain parameter prime generation process.

pgenCounter optionally specifies the integer value output as part of the of the domain parameter prime generation process.

   If either of the domain parameter generation components (pgenCounter
   or seed) is provided, the other MUST be present as well.

If either of the domain parameter generation components (pgenCounter or seed) is provided, the other MUST be present as well.

   The Diffie-Hellman public key MUST be ASN.1 encoded as an INTEGER;
   this encoding shall be used as the contents (i.e., the value) of the
   subjectPublicKey component (a BIT STRING) of the SubjectPublicKeyInfo
   data element.

The Diffie-Hellman public key MUST be ASN.1 encoded as an INTEGER; this encoding shall be used as the contents (i.e., the value) of the subjectPublicKey component (a BIT STRING) of the SubjectPublicKeyInfo data element.

      DHPublicKey ::= INTEGER -- public key, y = g^x mod p

DHPublicKey ::= INTEGER -- public key, y = g^x mod p

   If the keyUsage extension is present in a certificate which conveys a
   DH public key, the following values may be present:

If the keyUsage extension is present in a certificate which conveys a DH public key, the following values may be present:

      keyAgreement;
      encipherOnly; and
      decipherOnly.

keyAgreement; encipherOnly; and decipherOnly.

   If present, the keyUsage extension MUST assert keyAgreement and MAY
   assert either encipherOnly and decipherOnly.  The keyUsage extension
   MUST NOT assert both encipherOnly and decipherOnly.

If present, the keyUsage extension MUST assert keyAgreement and MAY assert either encipherOnly and decipherOnly. The keyUsage extension MUST NOT assert both encipherOnly and decipherOnly.

2.3.4 KEA Public Keys

2.3.4 KEA Public Keys

   This section identifies the preferred OID and parameters for the
   inclusion of a KEA public key in a certificate.  The Key Exchange
   Algorithm (KEA) is a key agreement algorithm.  Two parties may
   generate a "pairwise key" if and only if they share the same KEA
   parameters.  The KEA parameters are not included in a certificate;
   instead a domain identifier is supplied in the parameters field.

This section identifies the preferred OID and parameters for the inclusion of a KEA public key in a certificate. The Key Exchange Algorithm (KEA) is a key agreement algorithm. Two parties may generate a "pairwise key" if and only if they share the same KEA parameters. The KEA parameters are not included in a certificate; instead a domain identifier is supplied in the parameters field.

Polk, et al.                Standards Track                    [Page 11]

RFC 3279               Algorithms and Identifiers             April 2002

Polk, et al. Standards Track [Page 11] RFC 3279 Algorithms and Identifiers April 2002

   When the SubjectPublicKeyInfo field contains a KEA key, the algorithm
   identifier and parameters SHALL be as defined in [SDN.701r]:

When the SubjectPublicKeyInfo field contains a KEA key, the algorithm identifier and parameters SHALL be as defined in [SDN.701r]:

      id-keyExchangeAlgorithm  OBJECT IDENTIFIER   ::=
             { 2 16 840 1 101 2 1 1 22 }

id-keyExchangeAlgorithm OBJECT IDENTIFIER ::= { 2 16 840 1 101 2 1 1 22 }

      KEA-Parms-Id     ::= OCTET STRING

KEA-Parms-Id ::= OCTET STRING

   CAs MUST populate the parameters field of the AlgorithmIdentifier
   within the SubjectPublicKeyInfo field of each certificate containing
   a KEA public key with an 80-bit parameter identifier (OCTET STRING),
   also known as the domain identifier.  The domain identifier is
   computed in three steps:

CAs MUST populate the parameters field of the AlgorithmIdentifier within the SubjectPublicKeyInfo field of each certificate containing a KEA public key with an 80-bit parameter identifier (OCTET STRING), also known as the domain identifier. The domain identifier is computed in three steps:

      (1) the KEA domain parameters (p, q, and g) are DER encoded using
      the Dss-Parms structure;

(1) the KEA domain parameters (p, q, and g) are DER encoded using the Dss-Parms structure;

      (2) a 160-bit SHA-1 hash is generated from the parameters; and

(2) a 160-bit SHA-1 hash is generated from the parameters; and

      (3) the 160-bit hash is reduced to 80-bits by performing an
      "exclusive or" of the 80 high order bits with the 80 low order
      bits.

(3) the 160-bit hash is reduced to 80-bits by performing an "exclusive or" of the 80 high order bits with the 80 low order bits.

   The resulting value is encoded such that the most significant byte of
   the 80-bit value is the first octet in the octet string.  The Dss-
   Parms is provided above in Section 2.3.2.

結果として起こる値がコード化されるので、80ビットの価値の最も重要なバイトは八重奏ストリングで最初の八重奏です。 セクション2.3.2でDss- Parmsを上に提供します。

   A KEA public key, y, is conveyed in the subjectPublicKey BIT STRING
   such that the most significant bit (MSB) of y becomes the MSB of the
   BIT STRING value field and the least significant bit (LSB) of y
   becomes the LSB of the BIT STRING value field.  This results in the
   following encoding:

KEA公開鍵(y)がsubjectPublicKey BIT STRINGで伝えられるので、yの最も重要なビット(MSB)はBIT STRING値の分野のMSBになります、そして、yの最下位ビット(LSB)はBIT STRING値の分野のLSBになります。 これは以下のコード化をもたらします:

      BIT STRING tag;
      BIT STRING length;
      0 (indicating that there are zero unused bits in the final octet
      of y); and
      BIT STRING value field including y.

BIT STRINGタグ。 BIT STRINGの長さ。 0 (それを示して、y)の最終的な八重奏にはどんな未使用のビットもありません。 そして、BIT STRINGはyを含む分野を評価します。

   The key usage extension may optionally appear in a KEA certificate.
   If a KEA certificate includes the keyUsage extension, only the
   following values may be asserted:

主要な用法拡大はKEA証明書に任意に現れるかもしれません。 KEA証明書がkeyUsage拡張子を含んでいるなら、以下の値だけについて断言してもよいです:

      keyAgreement;
      encipherOnly; and
      decipherOnly.

keyAgreement。 encipherOnly。 そして、decipherOnly。

Polk, et al.                Standards Track                    [Page 12]

RFC 3279               Algorithms and Identifiers             April 2002

ポーク、他 標準化過程[12ページ]RFC3279アルゴリズムと識別子2002年4月

   If present, the keyUsage extension MUST assert keyAgreement and MAY
   assert either encipherOnly and decipherOnly.  The keyUsage extension
   MUST NOT assert both encipherOnly and decipherOnly.

存在しているなら、keyUsage拡張子は、keyAgreementについて断言しなければならなくて、encipherOnlyとdecipherOnlyについて断言するかもしれません。 keyUsage拡張子はencipherOnlyとdecipherOnlyの両方について断言してはいけません。

2.3.5 ECDSA and ECDH Keys

2.3.5 ECDSAとECDHキー

   This section identifies the preferred OID and parameter encoding for
   the inclusion of an ECDSA or ECDH public key in a certificate.  The
   Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in
   [X9.62].  ECDSA is the elliptic curve mathematical analog of the
   Digital Signature Algorithm [FIPS 186].  The Elliptic Curve Diffie
   Hellman (ECDH) algorithm is a key agreement algorithm defined in
   [X9.63].

このセクションは証明書でのECDSAかECDH公開鍵の包含のための都合のよいOIDとパラメタコード化を特定します。 Elliptic Curve Digital Signature Algorithm(ECDSA)は[X9.62]で定義されます。 ECDSAはDigital Signature Algorithm[FIPS186]の楕円曲線の数学のアナログです。 Elliptic Curveディフィー・ヘルマン(ECDH)アルゴリズムは[X9.63]で定義された主要な協定アルゴリズムです。

   ECDH is the elliptic curve mathematical analog of the Diffie-Hellman
   key agreement algorithm as specified in [X9.42].  The ECDSA and ECDH
   specifications use the same OIDs and parameter encodings.  The ASN.1
   object identifiers used to identify these public keys are defined in
   the following arc:

ECDHは[X9.42]の指定されるとしてのディフィー-ヘルマンの主要な協定アルゴリズムの楕円曲線の数学のアナログです。 ECDSAとECDH仕様は同じOIDsとパラメタencodingsを使用します。 これらの公開鍵を特定するのに使用されるASN.1オブジェクト識別子は以下のアークで定義されます:

   ansi-X9-62 OBJECT IDENTIFIER ::=
                             { iso(1) member-body(2) us(840) 10045 }

ansi-X9-62オブジェクト識別子:、:= iso(1)は(2) 私たち(840)10045をメンバーと同じくらい具体化させます。

   When certificates contain an ECDSA or ECDH public key, the
   id-ecPublicKey algorithm identifier MUST be used. The id-ecPublicKey
   algorithm identifier is defined as follows:

証明書がECDSAかECDH公開鍵を含むとき、イド-ecPublicKeyアルゴリズム識別子を使用しなければなりません。 イド-ecPublicKeyアルゴリズム識別子は以下の通り定義されます:

     id-public-key-type OBJECT IDENTIFIER  ::= { ansi-X9.62 2 }

イド公開鍵タイプOBJECT IDENTIFIER:、:= ansi-X9.62 2

     id-ecPublicKey OBJECT IDENTIFIER ::= { id-publicKeyType 1 }

イド-ecPublicKeyオブジェクト識別子:、:= イド-publicKeyType1

   This OID is used in public key certificates for both ECDSA signature
   keys and ECDH encryption keys.  The intended application for the key
   may be indicated in the key usage field (see [RFC 3280]).  The use of
   a single key for both signature and encryption purposes is not
   recommended, but is not forbidden.

このOIDはECDSA署名キーとECDH暗号化キーの両方に公開鍵証明書で使用されます。 キーの意図しているアプリケーションは主要な用法分野で示されるかもしれません([RFC3280]を見てください)。 単一のキーの署名と暗号化目的の両方の使用は、推薦されませんが、禁じられません。

   ECDSA and ECDH require use of certain parameters with the public key.
   The parameters may be inherited from the issuer, implicitly included
   through reference to a "named curve," or explicitly included in the
   certificate.

ECDSAとECDHは公開鍵がある、あるパラメタの使用を必要とします。 パラメタは、発行人から引き継がれるか、「命名されたカーブ」の参照でそれとなく含まれているか、または証明書に明らかに含まれるかもしれません。

      EcpkParameters ::= CHOICE {
        ecParameters  ECParameters,
        namedCurve    OBJECT IDENTIFIER,
        implicitlyCA  NULL }

EcpkParameters:、:= 選択ecParameters ECParameters、namedCurveオブジェクト識別子、implicitlyCAヌル

Polk, et al.                Standards Track                    [Page 13]

RFC 3279               Algorithms and Identifiers             April 2002

ポーク、他 標準化過程[13ページ]RFC3279アルゴリズムと識別子2002年4月

   When the parameters are inherited, the parameters field SHALL contain
   implictlyCA, which is the ASN.1 value NULL.  When parameters are
   specified by reference, the parameters field SHALL contain the
   named-Curve choice, which is an object identifier.  When the
   parameters are explicitly included, they SHALL be encoded in the
   ASN.1 structure ECParameters:

パラメタが引き継いでいるとき、パラメタ分野SHALLはimplictlyCAを含んでいます。(implictlyCAはASN.1値のNULLです)。 パラメタが参照で指定されるとき、パラメタ分野SHALLは命名されたカーブ選択を含んでいます。(それは、オブジェクト識別子です)。 含まれていて、パラメタは明らかにそうであり、それらはSHALLです。いつ、ASN.1構造ECParametersでコード化されてください:

      ECParameters ::= SEQUENCE {
         version   ECPVer,          -- version is always 1
         fieldID   FieldID,         -- identifies the finite field over
                                    -- which the curve is defined
         curve     Curve,           -- coefficients a and b of the
                                    -- elliptic curve
         base      ECPoint,         -- specifies the base point P
                                    -- on the elliptic curve
         order     INTEGER,         -- the order n of the base point
         cofactor  INTEGER OPTIONAL -- The integer h = #E(Fq)/n
         }

ECParameters:、:= 系列いつもバージョンが1fieldID FieldIDであるというECPVerが有限分野を特定するバージョン--、どれ、カーブは定義されたカーブCurveです--、係数aとb、楕円曲線オーダーINTEGER--ベースポイント補助因子INTEGER OPTIONALの注文n--整数h=#E(Fq)/nのベースポイントPを指定するか(楕円曲線ベースECPoint)。

      ECPVer ::= INTEGER {ecpVer1(1)}

ECPVer:、:= 整数ecpVer1(1)

      Curve ::= SEQUENCE {
         a         FieldElement,
         b         FieldElement,
         seed      BIT STRING OPTIONAL }

以下を曲がらせてください:= 系列FieldElement、b FieldElementはBIT STRING OPTIONALに種を蒔きます。

      FieldElement ::= OCTET STRING

FieldElement:、:= 八重奏ストリング

      ECPoint ::= OCTET STRING

ECPoint:、:= 八重奏ストリング

   The value of FieldElement SHALL be the octet string representation of
   a field element following the conversion routine in [X9.62], Section
   4.3.3.  The value of ECPoint SHALL be the octet string representation
   of an elliptic curve point following the conversion routine in
   [X9.62], Section 4.3.6.  Note that this octet string may represent an
   elliptic curve point in compressed or uncompressed form.

値、FieldElement SHALLでは、.3に[X9.62]、セクション4.3の変換ルーチンに従うフィールド要素の八重奏ストリング表現になってください。 値、ECPoint SHALLでは、.6に[X9.62]、セクション4.3の変換ルーチンに従う楕円曲線ポイントの八重奏ストリング表現になってください。 この八重奏ストリングが圧縮されたか解凍されたフォームに楕円曲線ポイントを表すかもしれないことに注意してください。

   Implementations that support elliptic curve according to this
   specification MUST support the uncompressed form and MAY support the
   compressed form.

この仕様通りに楕円曲線をサポートする実装は、解凍されたフォームをサポートしなければならなくて、圧縮形をサポートするかもしれません。

   The components of type ECParameters have the following meanings:

タイプECParametersの部品には、以下の意味があります:

      version specifies the version number of the elliptic curve
      parameters.  It MUST have the value 1 (ecpVer1).

バージョンは楕円曲線パラメタのバージョン番号を指定します。 それには、値1(ecpVer1)がなければなりません。

Polk, et al.                Standards Track                    [Page 14]

RFC 3279               Algorithms and Identifiers             April 2002

ポーク、他 標準化過程[14ページ]RFC3279アルゴリズムと識別子2002年4月

      fieldID identifies the finite field over which the elliptic curve
      is defined.  Finite fields are represented by values of the
      parameterized type FieldID, constrained to the values of the
      objects defined in the information object set FieldTypes.
      Additional detail regarding fieldID is provided below.

fieldIDは楕円曲線が定義される有限分野を特定します。 有限分野は情報オブジェクトセットFieldTypesで定義されたオブジェクトの値に抑制されたparameterizedタイプFieldIDの値によって表されます。 fieldIDに関する追加詳細は以下に明らかにされます。

      curve specifies the coefficients a and b of the elliptic curve E.
      Each coefficient is represented as a value of type FieldElement,
      an OCTET STRING. seed is an optional parameter used to derive the
      coefficients of a randomly generated elliptic curve.

カーブは係数aを指定します、そして、楕円曲線E.Each係数のbはタイプFieldElementの値として表されます、OCTET STRING。種子は手当たりしだいに発生している楕円曲線の係数を引き出すのに使用される任意のパラメタです。

      base specifies the base point P on the elliptic curve.  The base
      point is represented as a value of type ECPoint, an OCTET STRING.

ベースは楕円曲線のベースポイントPを指定します。 ベースポイントはタイプECPoint、OCTET STRINGの値として表されます。

      order specifies the order n of the base point.

オーダーはベースポイントの注文nを指定します。

      cofactor is the integer h = #E(Fq)/n.  This parameter is specified
      as OPTIONAL.  However, the cofactor MUST be included in ECDH
      public key parameters.  The cofactor is not required to support
      ECDSA, except in parameter validation.  The cofactor MAY be
      included to support parameter validation for ECDSA keys.
      Parameter validation is not required by this specification.

補助因子は整数h=#E(Fq)/nです。 このパラメタはOPTIONALとして指定されます。 しかしながら、ECDH公開鍵パラメタに補助因子を含まなければなりません。 補助因子は、パラメタ合法化以外に、ECDSAをサポートするのに必要ではありません。 補助因子は、ECDSAキーのためのパラメタ合法化をサポートするために含まれるかもしれません。 パラメタ合法化はこの仕様によって必要とされません。

   The AlgorithmIdentifier within SubjectPublicKeyInfo is the only place
   within a certificate where the parameters may be used.  If the
   elliptic curve parameters are specified as implicitlyCA in the
   SubjectPublicKeyInfo AlgorithmIdentifier and the CA signed the
   subject certificate using ECDSA, then the certificate issuer's ECDSA
   parameters apply to the subject's ECDSA key.  If the elliptic curve
   parameters are specified as implicitlyCA in the SubjectPublicKeyInfo
   AlgorithmIdentifier and the CA signed the certificate using a
   signature algorithm other than ECDSA, then clients MUST not make use
   of the elliptic curve public key.

SubjectPublicKeyInfoの中のAlgorithmIdentifierは証明書の中のパラメタが使用されるかもしれない唯一の場所です。 ECDSAを使用することでSubjectPublicKeyInfo AlgorithmIdentifierとカリフォルニアのimplicitlyCAが対象の証明書に署名したので楕円曲線パラメタが指定されるなら、証明書発行人のECDSAパラメタは対象のECDSAキーに適用されます。 ECDSA以外の署名アルゴリズムを使用することでSubjectPublicKeyInfo AlgorithmIdentifierとカリフォルニアのimplicitlyCAが証明書に署名したので楕円曲線パラメタが指定されるなら、クライアントは楕円曲線公開鍵を利用してはいけません。

      FieldID ::= SEQUENCE {
         fieldType   OBJECT IDENTIFIER,
         parameters  ANY DEFINED BY fieldType }

FieldID:、:= 系列fieldType OBJECT IDENTIFIER、パラメタいずれもDEFINED BY fieldType

   FieldID is a SEQUENCE of two components, fieldType and parameters.
   The fieldType contains an object identifier value that uniquely
   identifies the type contained in the parameters.

FieldIDは2つのコンポーネント、fieldType、およびパラメタのSEQUENCEです。 fieldTypeは唯一パラメタに含まれたタイプを特定するオブジェクト識別子価値を含んでいます。

   The object identifier id-fieldType specifies an arc containing the
   object identifiers of each field type.  It has the following value:

オブジェクト識別子イド-fieldTypeはそれぞれのフィールド・タイプのオブジェクト識別子を含むアークを指定します。 それには、以下の値があります:

      id-fieldType OBJECT IDENTIFIER ::= { ansi-X9-62 fieldType(1) }

イド-fieldTypeオブジェクト識別子:、:= ansi-X9-62 fieldType(1)

Polk, et al.                Standards Track                    [Page 15]

RFC 3279               Algorithms and Identifiers             April 2002

ポーク、他 標準化過程[15ページ]RFC3279アルゴリズムと識別子2002年4月

   The object identifiers prime-field and characteristic-two-field name
   the two kinds of fields defined in this Standard.  They have the
   following values:

識別子が最初さばくオブジェクトと2種類の分野がこのStandardで定義した独特の2フィールド名。 彼らには、以下の値があります:

      prime-field OBJECT IDENTIFIER ::= { id-fieldType 1 }

素体OBJECT IDENTIFIER:、:= イド-fieldType1

      Prime-p ::= INTEGER    -- Field size p (p in bits)

主要なp:、:= INTEGER--分野サイズp(ビットのp)

      characteristic-two-field OBJECT IDENTIFIER ::= { id-fieldType 2 }

独特の2分野OBJECT IDENTIFIER:、:= イド-fieldType2

      Characteristic-two ::= SEQUENCE {
         m           INTEGER,                      -- Field size 2^m
         basis       OBJECT IDENTIFIER,
         parameters  ANY DEFINED BY basis }

特性-2:、:= 系列m INTEGER--サイズ2^m基礎OBJECT IDENTIFIER、パラメタANY DEFINED BY基礎をさばいてください。

   The object identifier id-characteristic-two-basis specifies an arc
   containing the object identifiers for each type of basis for the
   characteristic-two finite fields.  It has the following value:

イド独特のtwo基礎がオブジェクト識別子を含むアークを指定するオブジェクト識別子はそれぞれ特性-2つの有限分野の基礎をタイプします。 それには、以下の値があります:

      id-characteristic-two-basis OBJECT IDENTIFIER ::= {
           characteristic-two-field basisType(1) }

イド独特のtwo基礎OBJECT IDENTIFIER:、:= 独特の2分野basisType(1)

   The object identifiers gnBasis, tpBasis and ppBasis name the three
   kinds of basis for characteristic-two finite fields defined by
   [X9.62].  They have the following values:

オブジェクト識別子のgnBasis、tpBasis、およびppBasisは特性-2の3種類の基礎を[X9.62]によって定義された有限分野と命名します。 彼らには、以下の値があります:

      gnBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 1 }

gnBasisオブジェクト識別子:、:= イド独特の2基礎1

      -- for gnBasis, the value of the parameters field is NULL

-- gnBasisに関しては、パラメタ分野の値はNULLです。

      tpBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 2 }

tpBasisオブジェクト識別子:、:= イド独特の2基礎2

      -- type of parameters field for tpBasis is Trinomial

-- tpBasisのためのパラメタ分野のタイプはTrinomialです。

      Trinomial ::= INTEGER

3項式:、:= 整数

      ppBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 3 }

ppBasisオブジェクト識別子:、:= イド独特の2基礎3

      -- type of parameters field for ppBasis is Pentanomial

-- ppBasisのためのパラメタ分野のタイプはPentanomialです。

      Pentanomial ::= SEQUENCE {
         k1  INTEGER,
         k2  INTEGER,
         k3  INTEGER }

Pentanomial:、:= 系列k1 INTEGER、k2 INTEGER、k3 INTEGER

Polk, et al.                Standards Track                    [Page 16]

RFC 3279               Algorithms and Identifiers             April 2002

ポーク、他 標準化過程[16ページ]RFC3279アルゴリズムと識別子2002年4月

   The elliptic curve public key (an ECPoint which is an OCTET STRING)
   is mapped to a subjectPublicKey (a BIT STRING) as follows:  the most
   significant bit of the OCTET STRING becomes the most significant bit
   of the BIT STRING, and the least significant bit of the OCTET STRING
   becomes the least significant bit of the BIT STRING.  Note that this
   octet string may represent an elliptic curve point in compressed or
   uncompressed form.  Implementations that support elliptic curve
   according to this specification MUST support the uncompressed form
   and MAY support the compressed form.

楕円曲線公開鍵(OCTET STRINGであるECPoint)は以下のsubjectPublicKey(BIT STRING)に写像されます: OCTET STRINGの最も重要なビットはBIT STRINGの最も重要なビットになります、そして、OCTET STRINGの最下位ビットはBIT STRINGの最下位ビットになります。 この八重奏ストリングが圧縮されたか解凍されたフォームに楕円曲線ポイントを表すかもしれないことに注意してください。 この仕様通りに楕円曲線をサポートする実装は、解凍されたフォームをサポートしなければならなくて、圧縮形をサポートするかもしれません。

   If the keyUsage extension is present in a CA or CRL issuer
   certificate which conveys an elliptic curve public key, any
   combination of the following values MAY be present:

keyUsage拡張子が楕円曲線公開鍵を伝えるカリフォルニアかCRL発行人証明書に存在しているなら、以下の値のどんな組み合わせも存在しているかもしれません:

      digitalSignature;
      nonRepudiation; and
      keyAgreement.

digitalSignature。 nonRepudiation。 そして、keyAgreement。

   If the keyAgreement value is present, either of the following values
   MAY be present:

keyAgreement値が存在しているなら、以下の値のどちらかが存在しているかもしれません:

      encipherOnly; and
      decipherOnly.

encipherOnly。 そして、decipherOnly。

   The keyUsage extension MUST NOT assert both encipherOnly and
   decipherOnly.

keyUsage拡張子はencipherOnlyとdecipherOnlyの両方について断言してはいけません。

   If the keyUsage extension is present in a CA certificate which
   conveys an elliptic curve public key, any combination of the
   following values MAY be present:

keyUsage拡張子が楕円曲線公開鍵を伝えるカリフォルニア証明書に存在しているなら、以下の値のどんな組み合わせも存在しているかもしれません:

      digitalSignature;
      nonRepudiation;
      keyAgreement;
      keyCertSign; and
      cRLSign.

digitalSignature。 nonRepudiation。 keyAgreement。 keyCertSign。 そして、cRLSign。

   As above, if the keyUsage extension asserts keyAgreement then it MAY
   assert either encipherOnly and decipherOnly.  However, this
   specification RECOMMENDS that if keyCertSign or cRLSign is present,
   keyAgreement, encipherOnly, and decipherOnly SHOULD NOT be present.

同じくらい上では、keyUsage拡張子がkeyAgreementについて断言するなら、それがencipherOnlyとdecipherOnlyについて断言するかもしれません。 しかしながら、keyCertSignかcRLSignが存在しているか、そして、keyAgreement、encipherOnly、およびdecipherOnly SHOULDがないこの仕様RECOMMENDS、プレゼント。

Polk, et al.                Standards Track                    [Page 17]

RFC 3279               Algorithms and Identifiers             April 2002

ポーク、他 標準化過程[17ページ]RFC3279アルゴリズムと識別子2002年4月

3  ASN.1 Module

3 ASN.1モジュール

   PKIX1Algorithms88 { iso(1) identified-organization(3) dod(6)
   internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
   id-mod-pkix1-algorithms(17) }

PKIX1Algorithms88iso(1)の特定された組織(3)dod(6)のインターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)イドモッズ-pkix1アルゴリズム(17)

   DEFINITIONS EXPLICIT TAGS ::= BEGIN

定義、明白なタグ:、:= 始まってください。

   -- EXPORTS All;

-- すべてをエクスポートします。

   -- IMPORTS NONE;

-- なにもインポートしません。

   --
   --   One-way Hash Functions
   --

-- -- 一方向ハッシュは機能します--

   md2  OBJECT IDENTIFIER ::= {
     iso(1) member-body(2) us(840) rsadsi(113549)
     digestAlgorithm(2) 2 }

md2 OBJECT IDENTIFIER:、:= iso(1)は(2) 私たち(840)rsadsi(113549) digestAlgorithm(2)2をメンバーと同じくらい具体化させます。

   md5  OBJECT IDENTIFIER ::= {
     iso(1) member-body(2) us(840) rsadsi(113549)
     digestAlgorithm(2) 5 }

md5 OBJECT IDENTIFIER:、:= iso(1)は(2) 私たち(840)rsadsi(113549) digestAlgorithm(2)5をメンバーと同じくらい具体化させます。

   id-sha1  OBJECT IDENTIFIER ::= {
     iso(1) identified-organization(3) oiw(14) secsig(3)
     algorithms(2) 26 }

イド-sha1 OBJECT IDENTIFIER:、:= iso(1)の特定された組織(3)oiw(14) secsig(3)アルゴリズム(2)26

   --
   --   DSA Keys and Signatures
   --

-- -- DSAキーと署名--

   -- OID for DSA public key

-- DSA公開鍵のためのOID

   id-dsa OBJECT IDENTIFIER ::= {
        iso(1) member-body(2) us(840) x9-57(10040) x9algorithm(4) 1 }

イド-dsa OBJECT IDENTIFIER:、:= iso(1)は(2) 私たち(840)x9-57(10040) x9algorithm(4)1をメンバーと同じくらい具体化させます。

   -- encoding for DSA public key

-- DSA公開鍵のためのコード化

   DSAPublicKey ::= INTEGER  -- public key, y

DSAPublicKey:、:= INTEGER--公開鍵、y

   Dss-Parms  ::=  SEQUENCE  {
      p             INTEGER,
      q             INTEGER,
      g             INTEGER  }

Dss-Parms:、:= 系列p INTEGER、q INTEGER、g INTEGER

Polk, et al.                Standards Track                    [Page 18]

RFC 3279               Algorithms and Identifiers             April 2002

ポーク、他 標準化過程[18ページ]RFC3279アルゴリズムと識別子2002年4月

   -- OID for DSA signature generated with SHA-1 hash

-- SHA-1ハッシュで生成されたDSA署名のためのOID

   id-dsa-with-sha1 OBJECT IDENTIFIER ::=  {
        iso(1) member-body(2) us(840) x9-57 (10040) x9algorithm(4) 3 }

sha1 OBJECT IDENTIFIERとイドdsa:、:= iso(1)は(2) 私たち(840)x9-57(10040)x9algorithm(4)3をメンバーと同じくらい具体化させます。

   -- encoding for DSA signature generated with SHA-1 hash

-- SHA-1ハッシュで生成されたDSA署名のためのコード化

   Dss-Sig-Value  ::=  SEQUENCE  {
      r       INTEGER,
      s       INTEGER  }

以下をDss-Sig評価してください:= 系列r整数、s整数

   --
   --   RSA Keys and Signatures
   --

-- -- RSAキーと署名--

   -- arc for RSA public key and RSA signature OIDs

-- RSA公開鍵とRSA署名OIDsのためのアーク

   pkcs-1 OBJECT IDENTIFIER ::= {
         iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 1 }

pkcs-1 OBJECT IDENTIFIER:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1)1をメンバーと同じくらい具体化させます。

   -- OID for RSA public keys

-- RSA公開鍵のためのOID

   rsaEncryption OBJECT IDENTIFIER ::=  { pkcs-1 1 }

rsaEncryptionオブジェクト識別子:、:= pkcs-1 1

   -- OID for RSA signature generated with MD2 hash

-- MD2ハッシュで生成されたRSA署名のためのOID

   md2WithRSAEncryption OBJECT IDENTIFIER  ::=  { pkcs-1 2 }

md2WithRSAEncryptionオブジェクト識別子:、:= pkcs-1 2

   -- OID for RSA signature generated with MD5 hash

-- MD5ハッシュで生成されたRSA署名のためのOID

   md5WithRSAEncryption OBJECT IDENTIFIER  ::=  { pkcs-1 4 }

md5WithRSAEncryptionオブジェクト識別子:、:= pkcs-1 4

   -- OID for RSA signature generated with SHA-1 hash

-- SHA-1ハッシュで生成されたRSA署名のためのOID

   sha1WithRSAEncryption OBJECT IDENTIFIER  ::=  { pkcs-1 5 }

sha1WithRSAEncryptionオブジェクト識別子:、:= pkcs-1 5

   -- encoding for RSA public key

-- RSA公開鍵のためのコード化

   RSAPublicKey ::= SEQUENCE {
      modulus            INTEGER,    -- n
      publicExponent     INTEGER  }  -- e

RSAPublicKey:、:= SEQUENCE、係数INTEGER--、n publicExponent INTEGER、--、e

Polk, et al.                Standards Track                    [Page 19]

RFC 3279               Algorithms and Identifiers             April 2002

ポーク、他 標準化過程[19ページ]RFC3279アルゴリズムと識別子2002年4月

   --
   --   Diffie-Hellman Keys
   --

-- -- ディフィー-ヘルマンKeys--

   dhpublicnumber OBJECT IDENTIFIER ::= {
        iso(1) member-body(2) us(840) ansi-x942(10046)
        number-type(2) 1 }

dhpublicnumber OBJECT IDENTIFIER:、:= iso(1)は(2) 私たち(840)ansi-x942(10046)No.タイプ(2)1をメンバーと同じくらい具体化させます。

   -- encoding for DSA public key

-- DSA公開鍵のためのコード化

   DHPublicKey ::= INTEGER  -- public key, y = g^x mod p

DHPublicKey:、:= INTEGER--公開鍵、yはg^xモッズpと等しいです。

   DomainParameters ::= SEQUENCE {
      p       INTEGER,           -- odd prime, p=jq +1
      g       INTEGER,           -- generator, g
      q       INTEGER,           -- factor of p-1
      j       INTEGER OPTIONAL,  -- subgroup factor, j>= 2
      validationParms  ValidationParms OPTIONAL }

DomainParameters:、:= 系列p INTEGER--奇素数、p=jqの+1gのINTEGER--ジェネレータ、g q INTEGER--p-1j INTEGER OPTIONALの要素--サブグループ要素、j>は2validationParms ValidationParms OPTIONALと等しいです。

   ValidationParms ::= SEQUENCE {
      seed             BIT STRING,
      pgenCounter      INTEGER }

ValidationParms:、:= 系列種子BIT STRING、pgenCounter INTEGER

   --
   --   KEA Keys
   --

-- -- ケアキー--

   id-keyExchangeAlgorithm  OBJECT IDENTIFIER  ::=
        { 2 16 840 1 101 2 1 1 22 }

イド-keyExchangeAlgorithmオブジェクト識別子:、:= { 2 16 840 1 101 2 1 1 22 }

   KEA-Parms-Id ::= OCTET STRING

ケアParmsイド:、:= 八重奏ストリング

   --
   --   Elliptic Curve Keys, Signatures, and Curves
   --

-- -- 楕円曲線キー、署名、およびカーブ--

   ansi-X9-62 OBJECT IDENTIFIER ::= {
        iso(1) member-body(2) us(840) 10045 }

ansi-X9-62オブジェクト識別子:、:= iso(1)は(2) 私たち(840)10045をメンバーと同じくらい具体化させます。

   FieldID ::= SEQUENCE {                    -- Finite field
      fieldType   OBJECT IDENTIFIER,
      parameters  ANY DEFINED BY fieldType }

FieldID:、:= 系列--、有限である、少しもfieldType OBJECT IDENTIFIER、パラメタをさばいてください、DEFINED BY fieldType

   -- Arc for ECDSA signature OIDS

-- ECDSA署名OIDSのためのアーク

   id-ecSigType OBJECT IDENTIFIER ::= { ansi-X9-62 signatures(4) }

イド-ecSigTypeオブジェクト識別子:、:= ansi-X9-62署名(4)

Polk, et al.                Standards Track                    [Page 20]

RFC 3279               Algorithms and Identifiers             April 2002

ポーク、他 標準化過程[20ページ]RFC3279アルゴリズムと識別子2002年4月

   -- OID for ECDSA signatures with SHA-1

-- SHA-1とのECDSA署名のためのOID

   ecdsa-with-SHA1 OBJECT IDENTIFIER ::= { id-ecSigType 1 }

SHA1とecdsaオブジェクト識別子:、:= イド-ecSigType1

   -- OID for an elliptic curve signature
   -- format for the value of an ECDSA signature value

-- 楕円曲線署名のためのOID--ECDSA署名価値の値のための形式

   ECDSA-Sig-Value ::= SEQUENCE {
      r     INTEGER,
      s     INTEGER }

以下をECDSA-Sig評価してください:= 系列r整数、s整数

   -- recognized field type OIDs are defined in the following arc

-- 認識されたフィールド・タイプOIDsは以下のアークで定義されます。

   id-fieldType OBJECT IDENTIFIER ::= { ansi-X9-62 fieldType(1) }

イド-fieldTypeオブジェクト識別子:、:= ansi-X9-62 fieldType(1)

   -- where fieldType is prime-field, the parameters are of type Prime-p

-- fieldTypeが素体であるところに、タイプPrime-pにはパラメタがあります。

   prime-field OBJECT IDENTIFIER ::= { id-fieldType 1 }

素体OBJECT IDENTIFIER:、:= イド-fieldType1

   Prime-p ::= INTEGER -- Finite field F(p), where p is an odd prime

主要なp:、:= INTEGER--有限分野F(p)。(そこでは、pが奇素数です)。

   -- where fieldType is characteristic-two-field, the parameters are
   -- of type Characteristic-two

-- fieldTypeが独特の2分野であるところに、タイプCharacteristic-twoにはパラメタがあります。

   characteristic-two-field OBJECT IDENTIFIER ::= { id-fieldType 2 }

独特の2分野OBJECT IDENTIFIER:、:= イド-fieldType2

   Characteristic-two ::= SEQUENCE {
      m           INTEGER,                   -- Field size 2^m
      basis       OBJECT IDENTIFIER,
      parameters  ANY DEFINED BY basis }

特性-2:、:= 系列m INTEGER--サイズ2^m基礎OBJECT IDENTIFIER、パラメタANY DEFINED BY基礎をさばいてください。

   -- recognized basis type OIDs are defined in the following arc

-- 認識された基礎タイプOIDsは以下のアークで定義されます。

   id-characteristic-two-basis OBJECT IDENTIFIER ::= {
        characteristic-two-field basisType(3) }

イド独特のtwo基礎OBJECT IDENTIFIER:、:= 独特の2分野basisType(3)

   -- gnbasis is identified by OID gnBasis and indicates
   -- parameters are NULL

-- gnbasisがそうである、OID gnBasisによって特定されて、表示、--パラメタがNULLである

   gnBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 1 }

gnBasisオブジェクト識別子:、:= イド独特の2基礎1

   -- parameters for this basis are NULL

-- この基礎のためのパラメタはNULLです。

   -- trinomial basis is identified by OID tpBasis and indicates
   -- parameters of type Pentanomial

-- 3項式基礎がOID tpBasisによって特定される、表示、--、タイプPentanomialのパラメタ

   tpBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 2 }

tpBasisオブジェクト識別子:、:= イド独特の2基礎2

Polk, et al.                Standards Track                    [Page 21]

RFC 3279               Algorithms and Identifiers             April 2002

ポーク、他 標準化過程[21ページ]RFC3279アルゴリズムと識別子2002年4月

   -- Trinomial basis representation of F2^m
   -- Integer k for reduction polynomial xm + xk + 1

-- F2^mの3項式基底表現--減少多項式xm+xk+1のための整数k

   Trinomial ::= INTEGER

3項式:、:= 整数

   -- for pentanomial basis is identified by OID ppBasis and indicates
   -- parameters of type Pentanomial

-- pentanomial基礎がOID ppBasisによって特定される、表示、--、タイプPentanomialのパラメタ

   ppBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 3 }

ppBasisオブジェクト識別子:、:= イド独特の2基礎3

   -- Pentanomial basis representation of F2^m
   -- reduction polynomial integers k1, k2, k3
   -- f(x) = x**m + x**k3 + x**k2 + x**k1 + 1

-- F2^mのPentanomial基底表現--減少多項式整数k1、k2、k3--f(x)=x**m+x**k3+x**k2+x**k1+1

   Pentanomial ::= SEQUENCE {
      k1  INTEGER,
      k2  INTEGER,
      k3  INTEGER }

Pentanomial:、:= 系列k1 INTEGER、k2 INTEGER、k3 INTEGER

   -- The object identifiers gnBasis, tpBasis and ppBasis name
   -- three kinds of basis for characteristic-two finite fields

-- オブジェクト識別子gnBasis、tpBasis、およびppBasis名--特性-2つの有限分野の3種類の基礎

   FieldElement ::= OCTET STRING             -- Finite field element

FieldElement:、:= OCTET STRING--有限フィールド要素

   ECPoint  ::= OCTET STRING                 -- Elliptic curve point

ECPoint:、:= OCTET STRING--楕円曲線ポイント

   -- Elliptic Curve parameters may be specified explicitly,
   -- specified implicitly through a "named curve", or
   -- inherited from the CA

-- または、楕円形のCurveパラメタは明らかに指定されるかもしれません--「命名されたカーブ」を通してそれとなく指定される、カリフォルニアから、引き継がれます。

   EcpkParameters ::= CHOICE {
      ecParameters  ECParameters,
      namedCurve    OBJECT IDENTIFIER,
      implicitlyCA  NULL }

EcpkParameters:、:= 選択ecParameters ECParameters、namedCurveオブジェクト識別子、implicitlyCAヌル

   ECParameters  ::= SEQUENCE {         -- Elliptic curve parameters
      version   ECPVer,
      fieldID   FieldID,
      curve     Curve,
      base      ECPoint,                -- Base point G
      order     INTEGER,                -- Order n of the base point
      cofactor  INTEGER  OPTIONAL }     -- The integer h = #E(Fq)/n

ECParameters:、:= SEQUENCEはnベースポイント補助因子INTEGER OPTIONALを命令します--楕円曲線パラメタバージョンECPVer、fieldID FieldID、カーブCurve、ベースECPoint(ポイントGオーダーINTEGERを基礎づけます)--整数hは#E(Fq)/nと等しいです。

   ECPVer ::= INTEGER {ecpVer1(1)}

ECPVer:、:= 整数ecpVer1(1)

Polk, et al.                Standards Track                    [Page 22]

RFC 3279               Algorithms and Identifiers             April 2002

ポーク、他 標準化過程[22ページ]RFC3279アルゴリズムと識別子2002年4月

   Curve  ::= SEQUENCE {
      a     FieldElement,            -- Elliptic curve coefficient a
      b     FieldElement,            -- Elliptic curve coefficient b
      seed  BIT STRING  OPTIONAL }

以下を曲がらせてください:= 系列FieldElement--楕円曲線係数a b FieldElement--楕円曲線係数b種子BIT STRING OPTIONAL

   id-publicKeyType OBJECT IDENTIFIER  ::= { ansi-X9-62 keyType(2) }

イド-publicKeyTypeオブジェクト識別子:、:= ansi-X9-62 keyType(2)

   id-ecPublicKey OBJECT IDENTIFIER ::= { id-publicKeyType 1 }

イド-ecPublicKeyオブジェクト識別子:、:= イド-publicKeyType1

   -- Named Elliptic Curves in ANSI X9.62.

-- ANSI X9.62で楕円曲線と命名されます。

   ellipticCurve OBJECT IDENTIFIER ::= { ansi-X9-62 curves(3) }

ellipticCurveオブジェクト識別子:、:= ansi-X9-62カーブ(3)

   c-TwoCurve OBJECT IDENTIFIER ::= {
        ellipticCurve characteristicTwo(0) }

c-TwoCurveオブジェクト識別子:、:= ellipticCurve characteristicTwo(0)

   c2pnb163v1  OBJECT IDENTIFIER  ::=  { c-TwoCurve  1 }
   c2pnb163v2  OBJECT IDENTIFIER  ::=  { c-TwoCurve  2 }
   c2pnb163v3  OBJECT IDENTIFIER  ::=  { c-TwoCurve  3 }
   c2pnb176w1  OBJECT IDENTIFIER  ::=  { c-TwoCurve  4 }
   c2tnb191v1  OBJECT IDENTIFIER  ::=  { c-TwoCurve  5 }
   c2tnb191v2  OBJECT IDENTIFIER  ::=  { c-TwoCurve  6 }
   c2tnb191v3  OBJECT IDENTIFIER  ::=  { c-TwoCurve  7 }
   c2onb191v4  OBJECT IDENTIFIER  ::=  { c-TwoCurve  8 }
   c2onb191v5  OBJECT IDENTIFIER  ::=  { c-TwoCurve  9 }
   c2pnb208w1  OBJECT IDENTIFIER  ::=  { c-TwoCurve 10 }
   c2tnb239v1  OBJECT IDENTIFIER  ::=  { c-TwoCurve 11 }
   c2tnb239v2  OBJECT IDENTIFIER  ::=  { c-TwoCurve 12 }
   c2tnb239v3  OBJECT IDENTIFIER  ::=  { c-TwoCurve 13 }
   c2onb239v4  OBJECT IDENTIFIER  ::=  { c-TwoCurve 14 }
   c2onb239v5  OBJECT IDENTIFIER  ::=  { c-TwoCurve 15 }
   c2pnb272w1  OBJECT IDENTIFIER  ::=  { c-TwoCurve 16 }
   c2pnb304w1  OBJECT IDENTIFIER  ::=  { c-TwoCurve 17 }
   c2tnb359v1  OBJECT IDENTIFIER  ::=  { c-TwoCurve 18 }
   c2pnb368w1  OBJECT IDENTIFIER  ::=  { c-TwoCurve 19 }
   c2tnb431r1  OBJECT IDENTIFIER  ::=  { c-TwoCurve 20 }

c2pnb163v1 OBJECT IDENTIFIER:、:= c-TwoCurve1c2pnb163v2 OBJECT IDENTIFIER:、:= c-TwoCurve2c2pnb163v3 OBJECT IDENTIFIER:、:= c-TwoCurve3c2pnb176w1 OBJECT IDENTIFIER:、:= c-TwoCurve4c2tnb191v1 OBJECT IDENTIFIER:、:= c-TwoCurve5c2tnb191v2 OBJECT IDENTIFIER:、:= c-TwoCurve6c2tnb191v3 OBJECT IDENTIFIER:、:= c-TwoCurve7c2onb191v4 OBJECT IDENTIFIER:、:= c-TwoCurve8c2onb191v5 OBJECT IDENTIFIER:、:= c-TwoCurve9c2pnb208w1 OBJECT IDENTIFIER:、:= c-TwoCurve10c2tnb239v1 OBJECT IDENTIFIER:、:= c-TwoCurve11c2tnb239v2 OBJECT IDENTIFIER:、:= c-TwoCurve12c2tnb239v3 OBJECT IDENTIFIER:、:= c-TwoCurve13c2onb239v4 OBJECT IDENTIFIER:、:= c-TwoCurve14c2onb239v5 OBJECT IDENTIFIER:、:= c-TwoCurve15c2pnb272w1 OBJECT IDENTIFIER:、:= c-TwoCurve16c2pnb304w1 OBJECT IDENTIFIER:、:= c-TwoCurve17c2tnb359v1 OBJECT IDENTIFIER:、:= c-TwoCurve18c2pnb368w1 OBJECT IDENTIFIER:、:= c-TwoCurve19c2tnb431r1 OBJECT IDENTIFIER:、:= c-TwoCurve20

   primeCurve OBJECT IDENTIFIER ::= { ellipticCurve prime(1) }

primeCurveオブジェクト識別子:、:= ellipticCurveは(1)を用意します。

   prime192v1  OBJECT IDENTIFIER  ::=  { primeCurve  1 }
   prime192v2  OBJECT IDENTIFIER  ::=  { primeCurve  2 }
   prime192v3  OBJECT IDENTIFIER  ::=  { primeCurve  3 }
   prime239v1  OBJECT IDENTIFIER  ::=  { primeCurve  4 }
   prime239v2  OBJECT IDENTIFIER  ::=  { primeCurve  5 }
   prime239v3  OBJECT IDENTIFIER  ::=  { primeCurve  6 }
   prime256v1  OBJECT IDENTIFIER  ::=  { primeCurve  7 }

prime192v1 OBJECT IDENTIFIER:、:= primeCurve1prime192v2 OBJECT IDENTIFIER:、:= primeCurve2prime192v3 OBJECT IDENTIFIER:、:= primeCurve3prime239v1 OBJECT IDENTIFIER:、:= primeCurve4prime239v2 OBJECT IDENTIFIER:、:= primeCurve5prime239v3 OBJECT IDENTIFIER:、:= primeCurve6prime256v1 OBJECT IDENTIFIER:、:= primeCurve7

   END

終わり

Polk, et al.                Standards Track                    [Page 23]

RFC 3279               Algorithms and Identifiers             April 2002

ポーク、他 標準化過程[23ページ]RFC3279アルゴリズムと識別子2002年4月

4  References

4つの参照箇所

   [FIPS 180-1]   Federal Information Processing Standards Publication
                  (FIPS PUB) 180-1, Secure Hash Standard, 17 April 1995.
                  [Supersedes FIPS PUB 180 dated 11 May 1993.]

[FIPS180-1] 連邦政府の情報処理規格公表(FIPSパブ)180-1、安全なハッシュ規格、1995年4月17日。 [1993年5月11日が日付を入れられたFIPS PUB180に取って代わります。]

   [FIPS 186-2]   Federal Information Processing Standards Publication
                  (FIPS PUB) 186, Digital Signature Standard, 27 January
                  2000. [Supersedes FIPS PUB 186-1 dated 15 December
                  1998.]

[FIPS186-2] 連邦政府の情報処理規格公表(FIPSパブ)186、デジタル署名基準、2000年1月27日。 [1998年12月15日が日付を入れられたFIPS PUB186-1に取って代わります。]

   [P1363]        IEEE P1363, "Standard Specifications for Public-Key
                  Cryptography", 2001.

[P1363]IEEE P1363、「公開鍵暗号のための標準の仕様」、2001。

   [RC95]         Rogier, N. and Chauvaud, P., "The compression function
                  of MD2 is not collision free," Presented at Selected
                  Areas in Cryptography '95, May 1995.

Cryptography95年、1995年5月のSelected Areasの[RC95]ロジエとN.と「MD2の圧縮機能には、衝突がないというわけではない」Chauvaud、P.、Presented。

   [RFC 1034]     Mockapetris, P., "Domain Names - Concepts and
                  Facilities", STD 13, RFC 1034, November 1987.

Mockapetris、[RFC1034]P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日

   [RFC 1319]     Kaliski, B., "The MD2 Message-Digest Algorithm", RFC
                  1319, April 1992.

[RFC1319] Kaliski、B.、「MD2メッセージダイジェストアルゴリズム」、RFC1319、1992年4月。

   [RFC 1321]     Rivest, R., "The MD5 Message-Digest Algorithm", RFC
                  1321, April 1992.

[RFC1321] Rivest、R.、「MD5メッセージダイジェストアルゴリズム」、RFC1321、1992年4月。

   [RFC 1422]     Kent, S., "Privacy Enhancement for Internet Electronic
                  Mail: Part II: Certificate-Based Key Management", RFC
                  1422, February 1993.

ケント、[RFC1422]S.、「インターネット電子メールのためのプライバシー増進:」 パートII: 「証明書ベースのKey Management」、RFC1422、1993年2月。

   [RFC 1423]     Balenson, D., "Privacy Enhancement for Internet
                  Electronic Mail: Part III: Algorithms, Modes, and
                  Identifiers", RFC 1423, February 1993.

Balenson、[RFC1423]D.、「インターネット電子メールのためのプライバシー増進:」 パートIII: 「アルゴリズム、モード、および識別子」、RFC1423、2月1993日

   [RFC 2119]     Bradner, S., "Key Words for Use in RFCs to Indicate
                  Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119] ブラドナー、S.、「使用のための要件レベルを示すRFCsのキーワード」、BCP14、RFC2119、1997年3月。

   [RFC 2313]     Kaliski, B., "PKCS #1: RSA Encryption Version 1.5",
                  RFC 2313, March 1998.

Kaliski、[RFC2313]B.、「PKCS#1:」 1.5インチ(RFC2313)が1998に行進させるRSA暗号化バージョン

   [RFC 2459]     Housley, R., Ford, W., Polk, W. and D. Solo "Internet
                  X.509 Public Key Infrastructure: Certificate and CRL
                  Profile", RFC 2459, January, 1999.

[RFC2459]のHousley、R.、フォード、W.、ポーク、W.、およびD.が独奏される、「インターネットX.509公開鍵基盤:」 「証明書とCRLプロフィール」、RFC2459、1月、1999

   [RFC 3174]     Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1
                  (SHA1)", RFC 3174, September 2001.

[RFC3174] イーストレークとD.とP.ジョーンズ、「米国安全なハッシュアルゴリズム1(SHA1)」、RFC3174 2001年9月。

Polk, et al.                Standards Track                    [Page 24]

RFC 3279               Algorithms and Identifiers             April 2002

ポーク、他 標準化過程[24ページ]RFC3279アルゴリズムと識別子2002年4月

   [RFC 3280]     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.

[RFC3280] HousleyとR.とポークとW.とフォードとW.と一人で生活して、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト(CRL)は輪郭を描く」D.、RFC3280、2002年4月。

   [SDN.701r]     SDN.701, "Message Security Protocol 4.0", Revision A
                  1997-02-06.

[SDN.701r]SDN.701、「メッセージセキュリティは4インチについて議定書の中で述べて、改正は1997年2月6日です」。

   [X.208]        CCITT Recommendation X.208: Specification of Abstract
                  Syntax Notation One (ASN.1), 1988.

[X.208]CCITT推薦X.208: 抽象構文記法1(ASN.1)の仕様、1988。

   [X.660]        ITU-T Recommendation X.660 Information Technology -
                  ASN.1 encoding rules: Specification of Basic Encoding
                  Rules (BER), Canonical Encoding Rules (CER) and
                  Distinguished Encoding Rules (DER), 1997.

[X.660]ITU-T Recommendation X.660情報Technology--ASN.1符号化規則: 基本的な符号化規則(BER)、正準な符号化規則(CER)、および顕著なコード化の仕様は(DER)、1997を統治します。

   [X9.42]        ANSI X9.42-2000, "Public Key Cryptography for The
                  Financial Services Industry: Agreement of Symmetric
                  Keys Using Discrete Logarithm Cryptography", December,
                  1999.

[X9.42]ANSI X9.42-2000、「財政的のための公開鍵暗号は産業にサービスを提供します」。 1999年12月の「離散対数暗号を使用する対称鍵の協定。」

   [X9.62]        X9.62-1998, "Public Key Cryptography For The Financial
                  Services Industry: The Elliptic Curve Digital
                  Signature Algorithm (ECDSA)", January 7, 1999.

[X9.62]X9.62-1998、「財政的のための公開鍵暗号は産業にサービスを提供します」。 1999年1月7日の「楕円曲線デジタル署名アルゴリズム(ECDSA)。」

   [X9.63]        ANSI X9.63-2001, "Public Key Cryptography For The
                  Financial Services Industry: Key Agreement and Key
                  Transport Using Elliptic Curve Cryptography", Work in
                  Progress.

[X9.63]ANSI X9.63-2001、「財政的のための公開鍵暗号は産業にサービスを提供します」。 「楕円曲線暗号を使用する主要な協定と主要な輸送」は進行中で働いています。

5  Security Considerations

5 セキュリティ問題

   This specification does not constrain the size of public keys or
   their parameters for use in the Internet PKI.  However, the key size
   selected impacts the strength achieved when implementing
   cryptographic services.  Selection of appropriate key sizes is
   critical to implementing appropriate security.

この仕様は公開鍵のサイズかインターネットPKIでの使用のためのそれらのパラメタを抑制しません。 しかしながら、主要なサイズは暗号のサービスを実行するとき強さが実現した衝撃を選択しました。 適切な主要なサイズの品揃えは適切なセキュリティを実行するのに重要です。

   This specification does not identify particular elliptic curves for
   use in the Internet PKI.  However, the particular curve selected
   impact the strength of the digital signatures.  Some curves are
   cryptographically stronger than others!

この仕様はインターネットPKIでの使用のために特定の楕円曲線を特定しません。 しかしながら、選択された特定のカーブはデジタル署名の強さに影響を与えます。 いくつかのカーブが暗号でそうである、他のものより強い!

   In general, use of "well-known" curves, such as the "named curves"
   from ANSI X9.62, is a sound strategy.  For additional information,
   refer to X9.62 Appendix H.1.3, "Key Length Considerations" and
   Appendix A.1, "Avoiding Cryptographically Weak Keys".

一般に、ANSI X9.62からの「命名されたカーブ」などの「周知」のカーブの使用は健全な戦略です。 「暗号で、弱いキーを避け」て、追加情報について、X9.62 Appendix H.1.3、「キー長問題」、およびAppendix A.1を参照してください。

Polk, et al.                Standards Track                    [Page 25]

RFC 3279               Algorithms and Identifiers             April 2002

ポーク、他 標準化過程[25ページ]RFC3279アルゴリズムと識別子2002年4月

   This specification supplements RFC 3280.  The security considerations
   section of that document applies to this specification as well.

この仕様はRFC3280を補います。 そのドキュメントのセキュリティ問題部はまた、この仕様に適用されます。

6  Intellectual Property Rights

6 知的所有権

   The IETF has been notified of intellectual property rights claimed in
   regard to some or all of the specification contained in this
   document.  For more information consult the online list of claimed
   rights.

IETFは本書では含まれた仕様いくつかかすべてに関して要求された知的所有権について通知されました。 詳しい情報に関しては、要求された権利のオンラインリストに相談してください。

   The IETF takes no position regarding the validity or scope of any
   intellectual property 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; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards- related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication 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 implementors or users of this specification can
   be obtained from the IETF Secretariat.

IETFはどんな知的所有権の正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。いずれもどんなそのような権利も特定するための努力にしました。 BCP-11で標準化過程の権利と規格の関連するドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可が作成者によるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、またはIETF事務局からこの仕様のユーザを得ることができます。

7  Author Addresses:

7 アドレスを書いてください:

   Tim Polk
   NIST
   100 Bureau Drive, Stop 8930
   Gaithersburg, MD 20899-8930
   USA
   EMail: tim.polk@nist.gov

ティムポークNIST100事務局Drive、8930年の停止ゲイザースバーグ、MD20899-8930米国メール: tim.polk@nist.gov

   Russell Housley
   RSA Laboratories
   918 Spring Knoll Drive
   Herndon, VA 20170
   USA
   EMail: rhousley@rsasecurity.com

ラッセルHousley RSA研究所918は小山Driveハーンドン(ヴァージニア)20170米国メールを跳ばせます: rhousley@rsasecurity.com

   Larry Bassham
   NIST
   100 Bureau Drive, Stop 8930
   Gaithersburg, MD 20899-8930
   USA
   EMail: lbassham@nist.gov

ラリーBassham NIST100事務局Drive、8930年の停止ゲイザースバーグ、MD20899-8930米国メール: lbassham@nist.gov

Polk, et al.                Standards Track                    [Page 26]

RFC 3279               Algorithms and Identifiers             April 2002

ポーク、他 標準化過程[26ページ]RFC3279アルゴリズムと識別子2002年4月

8.  Full Copyright Statement

8. 完全な著作権宣言文

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Copyright(C)インターネット協会(2002)。 All rights reserved。

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Acknowledgement

承認

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Polk, et al.                Standards Track                    [Page 27]

ポーク、他 標準化過程[27ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

AND演算子 論理積

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る