RFC5276 日本語訳

5276 Using the Server-Based Certificate Validation Protocol (SCVP) toConvey Long-Term Evidence Records. C. Wallace. August 2008. (Format: TXT=27422 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文

Network Working Group                                         C. Wallace
Request for Comments: 5276                            Cygnacom Solutions
Category: Standards Track                                    August 2008

コメントを求めるワーキンググループC.ウォレス要求をネットワークでつないでください: 5276年のCygnacomソリューションカテゴリ: 標準化過程2008年8月

   Using the Server-Based Certificate Validation Protocol (SCVP) to
                   Convey Long-Term Evidence Records

長期の証拠記録を伝えるのに、サーバベースの証明書合法化プロトコル(SCVP)を使用します。

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.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Abstract

要約

   The Server-based Certificate Validation Protocol (SCVP) defines an
   extensible means of delegating the development and validation of
   certification paths to a server.  It can be used to support the
   development and validation of certification paths well after the
   expiration of the certificates in the path by specifying a time of
   interest in the past.  The Evidence Record Syntax (ERS) defines
   structures, called evidence records, to support the non-repudiation
   of the existence of data.  Evidence records can be used to preserve
   materials that comprise a certification path such that trust in the
   certificates can be established after the expiration of the
   certificates in the path and after the cryptographic algorithms used
   to sign the certificates in the path are no longer secure.  This
   document describes usage of the SCVP WantBack feature to convey
   evidence records, enabling SCVP responders to provide preservation
   evidence for certificates and certificate revocation lists (CRLs).

ServerベースのCertificate Validationプロトコル(SCVP)は開発を代表として派遣する広げることができる手段と証明経路の合法化をサーバと定義します。経路での証明書の満了のよく後に過去に興味がある時間を指定することによって証明経路の開発と合法化をサポートするのにそれは使用できます。 Evidence Record Syntax(ERS)は、データの存在の非拒否をサポートするために証拠記録と呼ばれる構造を定義します。 経路での証明書の満了、経路で証明書に署名するのに使用される暗号アルゴリズムがもう安全にならなかった後に証明書の信頼を確立できるように証明経路を含む材料を保存するのに証拠記録を使用できます。 このドキュメントは証拠記録を伝えるSCVP WantBackの特徴の用法を説明します、SCVP応答者が証明書と証明書失効リスト(CRLs)に関する保存証拠を提供するのを可能にして。

Wallace                     Standards Track                     [Page 1]

RFC 5276               Evidence Records via SCVP             August 2008

SCVP2008年8月を通したウォレスStandards Track[1ページ]RFC5276Evidence Records

Table of Contents

目次

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Requirements Notation  . . . . . . . . . . . . . . . . . .  3
   2.  Concept of Operations  . . . . . . . . . . . . . . . . . . . .  4
   3.  Requests . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Responses  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   5.  WantBacks  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     5.1.  Evidence Record for a Complete Certification Path  . . . .  7
     5.2.  Evidence Record for a Partial Certification Path . . . . .  7
     5.3.  Evidence Record for a Public Key Certificate . . . . . . .  8
     5.4.  Evidence Record for Revocation Information . . . . . . . .  8
     5.5.  Evidence Record for Any replyWantBack  . . . . . . . . . .  8
     5.6.  Partial Certification Path . . . . . . . . . . . . . . . .  9
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 10
   Appendix A.  ASN.1 Module  . . . . . . . . . . . . . . . . . . . . 11

1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1。 要件記法. . . . . . . . . . . . . . . . . . 3 2 作戦構想. . . . . . . . . . . . . . . . . . . . 4 3。 要求. . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4。 応答. . . . . . . . . . . . . . . . . . . . . . . . . . 6 5。 WantBacks. . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1。 完全な証明経路. . . . 7 5.2に記録を証明してください。 分割認定経路. . . . . 7 5.3に記録を証明してください。 公開鍵証明書. . . . . . . 8 5.4のために記録を証明してください。 取消し情報. . . . . . . . 8 5.5のために記録を証明してください。 あらゆるreplyWantBack. . . . . . . . . . 8 5.6のために記録を証明してください。 分割認定経路. . . . . . . . . . . . . . . . 9 6。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 10 7。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1。 引用規格. . . . . . . . . . . . . . . . . . . 10 7.2。 有益な参照. . . . . . . . . . . . . . . . . . 10付録A.ASN.1モジュール. . . . . . . . . . . . . . . . . . . . 11

Wallace                     Standards Track                     [Page 2]

RFC 5276               Evidence Records via SCVP             August 2008

SCVP2008年8月を通したウォレスStandards Track[2ページ]RFC5276Evidence Records

1.  Introduction

1. 序論

   Digital signatures are frequently verified using public key
   infrastructure (PKI) artifacts, including public key certificates and
   certificate revocation information.  Verifiers construct and validate
   certification paths from a public key certificate containing the
   public key used to verify the signature to a trusted public key.
   Construction of a certification path may require the acquisition of
   different types of information generated by multiple PKIs.  To verify
   digital signatures many years after signature generation, additional
   considerations must be addressed.  For example, some necessary PKI
   artifacts may no longer be available, some may have expired, and the
   cryptographic algorithms or keys used in generating digital
   signatures may no longer provide the desired degree of security.

公開鍵証明書と証明書取消し情報を含んでいて、デジタル署名は、公開鍵認証基盤(PKI)人工物を使用することで頻繁に確かめられます。 検証は、署名について確かめるのに使用される公開鍵を含む公開鍵証明書から信じられた公開鍵まで証明経路を組み立てて、有効にします。 証明経路の工事は複数のPKIsによって生成された異なったタイプの情報の獲得を必要とするかもしれません。 署名世代の何年も後にデジタル署名について確かめるために、追加問題を扱わなければなりません。 例えば、いくつかの必要なPKI人工物はもう利用可能でないかもしれません、そして、或るものは期限が切れたかもしれません、そして、デジタル署名を生成する際に使用される暗号アルゴリズムかキーがもう必要な度合いのセキュリティを提供しないかもしれません。

   SCVP [RFC5055] provides a means of delegating certification path
   construction and/or validation to a server, including the ability to
   request the status of a certificate relative to a time in the past.
   SCVP does not define a means of providing or validating long-term
   non-repudiation information.  ERS [RFC4998] defines a syntax for
   preserving materials over long periods of time through a regimen that
   includes periodic re-signing of relevant materials using newer keys
   and stronger cryptographic algorithms.  LTAP [LTANS-LTAP] defines a
   protocol for communicating with a long-term archive (LTA) server for
   the purpose of preserving evidence records and data.  Clients store,
   retrieve, and delete data using LTAP; LTAs maintain evidence records
   covering data submitted by clients.

SCVP[RFC5055]は証明経路工事、そして/または、合法化をサーバへ代表として派遣する手段を提供します、過去の時間に比例して証明書の状態を要求する能力を含んでいて。 SCVPは長期の非拒否情報を提供するか、または有効にする手段を定義しません。 ERS[RFC4998]は長期間の間、より新しいキーと、より強い暗号アルゴリズムを使用することで関連材料の周期的な再契約を含んでいる養生法で材料を保存するための構文を定義します。LTAP[LTANS-LTAP]は、証拠記録とデータを保持する目的のために長期のアーカイブ(LTA)サーバとコミュニケートするためにプロトコルを定義します。 クライアントは、LTAPを使用することでデータを保存して、検索して、削除します。 LTAsはクライアントによって提出されたデータをカバーする証拠記録を保守します。

   This document defines an application of SCVP to permit retrieval of
   an evidence record corresponding to information returned by the SCVP
   server by creating an association between an evidence record and
   information contained in an SCVP response.  The SCVP response can
   then in turn be used to verify archived data objects retrieved using
   LTAP.  Separating the preservation of the certification path
   information from the preservation of data enables the LTA to store
   archived data objects more efficiently, i.e., complete verification
   information need not be stored with each archived data object.
   Verifiers can more efficiently process archived data objects by
   reusing the same certification path information to verify multiple
   archived data objects of similar vintage without retrieving and/or
   validating the same PKI artifacts multiple times.

このドキュメントは、証拠記録とSCVP応答で含まれた情報との協会を創設することによってSCVPサーバによって返された情報に対応する証拠記録の検索を可能にするためにSCVPのアプリケーションを定義します。 そして、LTAPを使用することで検索された格納されたデータ・オブジェクトについて確かめるのに順番にSCVP応答を使用できます。 データの保存と証明経路情報の保存を切り離すのは、LTAが、より効率的に格納されたデータ・オブジェクトを保存するのを可能にします、すなわち、完全な検証情報がそれぞれの格納されたデータ・オブジェクトで保存される必要はありません。 検証は、複数の回同じPKI人工物を検索する、そして/または、有効にしないで同様のヴィンテージの複数の格納されたデータ・オブジェクトについて確かめるために同じ証明経路情報を再利用することによって、より効率的に格納されたデータ・オブジェクトを処理できます。

1.1.  Requirements Notation

1.1. 要件記法

   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].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?

Wallace                     Standards Track                     [Page 3]

RFC 5276               Evidence Records via SCVP             August 2008

SCVP2008年8月を通したウォレスStandards Track[3ページ]RFC5276Evidence Records

2.  Concept of Operations

2. 作戦構想

   During certification path processing, active SCVP servers may
   encounter a large portion of the PKI artifacts generated by a
   particular PKI.  By storing and preserving these artifacts, an SCVP
   server can respond to queries for certificate status over very long
   periods of time.  Optionally, SCVP servers may actively seek PKI
   information for storage and preservation, even when no query is made,
   that requires the information during its period of validity in order
   to service future queries relative to any point in time.

証明経路処理の間、アクティブなSCVPサーバは特定のPKIによって生成されたPKI人工物の大半に遭遇するかもしれません。 これらの人工物を保存して、保存することによって、SCVPサーバは非常に長い期間にわたって証明書状態のための質問に反応できます。 質問を全くしてさえいないとき、任意に、SCVPサーバは活発にストレージと保存のためのPKI情報を求めるかもしれなくて、それは、時間内に任意な点に比例して今後の質問を修理するために正当性の期間、情報を必要とします。

   SCVP permits clients to request as much or as little information as
   desired from the SCVP server.  Clients include zero or more Object
   Identifiers (OIDs) indicating the type(s) of information the server
   should include in the response.  By defining additional OID values,
   clients can request an evidence record for specific types of
   information returned by the SCVP server.  This document defines OIDs
   to permit the retrieval of evidence records for the following four
   types of information:

SCVPは同じくらい非常に要求するクライアントか. クライアントが含むSCVPサーバから望まれているのと同じくらい少ない情報にゼロを可能にするか、またはサーバが応答に含むべきである情報のタイプをより多くのObject Identifiers(OIDs)表示に可能にします。 追加OID値を定義することによって、クライアントはSCVPサーバによって返された特定のタイプの情報のための証拠記録を要求できます。このドキュメントは以下の4つのタイプの情報のための証拠記録の検索を可能にするためにOIDsを定義します:

   o  end entity certificates.

o 実体証明書を終わらせてください。

   o  certification paths containing an end entity certificate up to a
      trust anchor.

o 終わりの実体証明書を信頼まで含む証明経路が投錨されます。

   o  certification paths containing an intermediate certificate up to a
      trust anchor.

o 中間的証明書を信頼まで含む証明経路が投錨されます。

   o  revocation information.

o 取消し情報。

   Additionally, an OID is defined to permit inclusion of a single OID
   indicating an evidence record is desired for all information
   requested via the WantBack mechanism.

さらに、OIDは、証拠記録がWantBackメカニズムで要求されたすべての情報のために望まれているのを示す独身のOIDの包含を可能にするために定義されます。

   By associating evidence records with information maintained by an
   SCVP server, clients are able to determine the status of certificates
   over very long periods of time using SCVP without consulting
   additional resources.  The nature of SCVP servers is well suited to
   the preservation of infrastructure materials.  Additionally, the SCVP
   server's signature over an SCVP response can secure the transmission
   of trust anchors included in evidence records, allowing clients to
   refrain from establishing additional trust relationships with LTAs.

SCVPサーバによって保守される情報に証拠記録を関連づけることによって、クライアントは非常に長い期間にわたって追加リソースに相談しないでSCVPを使用することで証明書の状態を決定できます。 SCVPサーバの本質はインフラストラクチャの材料の保存によく合っています。 さらに、証拠記録にアンカーを含んでいる場合、SCVP応答の上のSCVPサーバの署名は信頼の送信を保証できます、クライアントが、LTAsとの追加信頼関係を確立するのを控えるのを許容して。

   The transactions used to verify an archived data object using LTAP
   and the SCVP WantBacks described in this document are as follows:

トランザクションは以前はLTAPを使用することで格納されたデータ・オブジェクトについてよく確かめていました、そして、本書では説明されたSCVP WantBacksは以下の通りです:

   o  Client retrieves a signed archived data object from an LTA using
      LTAP.

o クライアントは、LTAからLTAPを使用することで署名している格納されたデータ・オブジェクトを検索します。

Wallace                     Standards Track                     [Page 4]

RFC 5276               Evidence Records via SCVP             August 2008

SCVP2008年8月を通したウォレスStandards Track[4ページ]RFC5276Evidence Records

   o  Client prepares an SCVP request to validate the signer's
      certificate at the time of interest and includes WantBacks for
      evidence records corresponding to the PKI artifacts required to
      validate the signer's certificate.

o クライアントは、関心時点で、署名者の証明書を有効にするというSCVP要求を準備して、PKI人工物に対応する記録が署名者の証明書を有効にするのが必要であるという証拠のためにWantBacksを入れます。

   o  SCVP server returns a response with status as of the time of
      interest and includes requested evidence records.

o SCVPサーバは、興味がある時現在、状態がある応答を返して、要求された証拠記録を含んでいます。

   o  Client processes the SCVP request, determines the status, and
      verifies the evidence records.

o クライアントは、SCVP要求を処理して、状態を決定して、証拠記録について確かめます。

   o  Client verifies signatures in the archived data object using the
      validated signer's certificate.

o クライアントは、格納されたデータ・オブジェクトで有効にされた署名者の証明書を使用することで署名について確かめます。

3.  Requests

3. 要求

   Clients request long-term archive evidence records from an SCVP
   server by including one of the following OIDs in the wantBack field
   of a CVRequest sent to an SCVP server:

クライアントはSCVPサーバからSCVPサーバに送られたCVRequestのwantBack分野に以下のOIDsの1つを含んでいることによって、長期のアーカイブ証拠記録を要求します:

   o  id-swb-ers-best-cert-path

o イドのswb-ersの最も良い本命道

   o  id-swb-ers-partial-cert-path

o イドのswb-ersの部分的な本命道

   o  id-swb-ers-pkc-cert

o イドswb-ers-pkc本命

   o  id-swb-ers-revocation-info

o イドswb-ers取消しインフォメーション

   o  id-swb-ers-all

o イドswb-ers、すべて

   Additionally, id-swb-partial-cert-path is defined to permit clients
   to request a partial certification path consisting of the
   certification authority (CA) that issued the end entity certificate
   through a trust anchor.  This is similar to the id-swb-best-cert-path
   WantBack defined in SCVP except the resulting replyWantBack will
   contain a CertBundle containing the certification path minus the end
   entity certificate.

さらに、イドのswbの部分的な本命道は、クライアントが信頼アンカーを通して終わりの実体証明書を発行した証明権威(カリフォルニア)から成る分割認定経路を要求することを許可するために定義されます。 これはイドのswbのWantBackがSCVPで定義した中で最も良い本命道と同様です、そして、結果として起こるreplyWantBackは終わりの実体証明書を引いて証明経路を含むCertBundleを含むでしょう。

   For each id-swb-ers OID except id-swb-ers-all, an EvidenceRecord (as
   defined in [RFC4998]) covering the corresponding information in the
   response will be returned as a replyWantBack.  For example, if a
   client wishes to obtain a certification path and revocation
   information plus an evidence record for each, the SCVP request would
   include the following four replyWantBack OIDs: id-swb-best-cert-path,
   id-swb-pkc-revocation-info, id-swb-ers-best-cert-path, and id-swb-
   ers-revocation-info.

各イド-swb-ers OIDが除く、イドswb-ers、すべて、replyWantBackとして応答における対応する情報をカバーするEvidenceRecord([RFC4998]で定義されるように)を返すでしょう。 例えば、クライアントがそれぞれのための証明経路、取消し情報、および証拠記録を得たいなら、SCVP要求は以下の4replyWantBack OIDsを含んでいるでしょう: イドのswbの最も良い本命道、イドswb-pkc取消しインフォメーション、イドのswb-ersの最も良い本命道、およびイドswb- ers取消しインフォメーション。

Wallace                     Standards Track                     [Page 5]

RFC 5276               Evidence Records via SCVP             August 2008

SCVP2008年8月を通したウォレスStandards Track[5ページ]RFC5276Evidence Records

   Alternatively, for id-swb-ers-all, an EvidenceRecordWantBacks
   structure will be returned containing an EvidenceRecord for each
   information item contained in the replyWantBacks field.  For example,
   if a client wishes to obtain a certification path and revocation
   information plus an evidence record for each, the SCVP request could
   include the following three replyWantBack OIDs: id-swb-best-cert-
   path, id-swb-pkc-revocation-info, and id-swb-ers-all.

代わりに、イドswb-ers、すべて、replyWantBacks分野に保管されていたそれぞれの情報項目のためのEvidenceRecordを含んでいて、EvidenceRecordWantBacks構造を返すでしょう。 例えば、クライアントがそれぞれのための証明経路、取消し情報、および証拠記録を得たいなら、SCVP要求は以下の3replyWantBack OIDsを含むかもしれません: そして、イド-swb最も良い本命道、イドswb-pkc取消しインフォメーション、イドswb-ers、すべて

4.  Responses

4. 応答

   When a client request contains a WantBack request for an evidence
   record, the response generated MUST include the replyWantBack
   containing the requested information plus a replyWantBack containing
   the evidence record corresponding to that information.  For each id-
   swb-ers OID except id-swb-ers-pkc-cert and id-swb-ers-revocation-
   info, the evidence record MUST be calculated over the value of the
   value field in the corresponding replyWantBack; the tag and length
   bytes are not covered by the evidence record.  The targets for the
   id-swb-ers-pkc-cert and id-swb-ers-revocation-info replyWantBacks are
   described below.  For example, if a client request contains id-swb-
   pkc-best-cert-path and id-swb-ers-best-cert-path, the resulting
   response will contain a replyWantBack of each type where the evidence
   record covers the DER-encoded CertBundle returned in the id-swb-pkc-
   best-cert-path replyWantBack.  For id-swb-ers-pkc-cert, the evidence
   record MUST be calculated over the value of the cert field in the
   CertReply object.  For id-swb-ers-revocation-info, a sequence of
   evidence records is returned.  Each revocation information object
   contained in the id-swb-pkc-revocation-info replyWantBack is covered
   by an evidence record in the id-swb-ers-revocation-info
   replyWantBack.  A single evidence record may cover multiple
   revocation information objects.  The correct evidence record can be
   identified by locating the hash of the revocation information object
   in the first initial timestamp of the evidence record.

クライアント要求が証拠記録に関するWantBack要求を含むとき、生成された応答は求められた情報を含むreplyWantBackとその情報に対応する証拠記録を含むreplyWantBackを含まなければなりません。 イドswb-ers-pkc本命とイド-swb-ers取消しインフォメーション以外のそれぞれのイドswb-ers OIDに関しては、対応するreplyWantBackの値の分野の値に関して証拠記録について計算しなければなりません。 タグと長さのバイトは証拠記録で含まれていません。 イドswb-ers-pkc本命とイドswb-ers取消しインフォメーションreplyWantBacksのための目標は以下で説明されます。 例えば、クライアント要求がイドのswb- pkcの最も良い本命道とイドのswb-ersの最も良い本命道を含んでいると、結果として起こる応答は証拠記録がDERによってコード化されたCertBundleをイドでswb-pkcを返してカバーするところで最も良い本命道のreplyWantBackをタイプでそれぞれのreplyWantBackを含むでしょう。 イドswb-ers-pkc本命に関しては、CertReplyオブジェクトの本命分野の値に関して証拠記録について計算しなければなりません。 イドswb-ers取消しインフォメーションに関しては、証拠記録の系列は返されます。 イドswb-pkc取消しインフォメーションreplyWantBackに含まれたそれぞれの取消し情報オブジェクトはイドswb-ers取消しインフォメーションreplyWantBackでの証拠記録でカバーされています。 ただ一つの証拠記録は複数の取消し情報オブジェクトをカバーするかもしれません。 証拠記録に関する先頭の頭文字タイムスタンプで取消し情報オブジェクトのハッシュの場所を見つけることによって、正しい証拠記録を特定できます。

   If the server cannot return an EvidenceRecord for the requested
   information item, a replyWantBack of the appropriate type MUST be
   returned with an empty value field.  For example, if a client
   requests id-swb-ers-pkc-cert and the server cannot fulfill the
   request, the resulting response will contain a replyWantBack with the
   wb field set to id-swb-ers-pkc-cert and the value field empty, i.e.,
   zero length.

サーバが求められた情報項目のためにEvidenceRecordを返すことができないなら、人影のない値の分野と共に適切なタイプのreplyWantBackを返さなければなりません。 例えば、クライアントが、イドswb-ers-pkc本命とサーバが要求を実現させることができないよう要求すると、結果として起こる応答はイドswb-ers-pkc本命に設定されたwb分野と値の分野が人影がないreplyWantBackを含むでしょう、すなわち、ゼロ・レングス。

5.  WantBacks

5. WantBacks

   The following sections describe each WantBack defined in this
   document.  Each WantBack for an evidence record requires a
   corresponding WantBack for the object covered by the evidence record
   to be present in the request.  Upon receipt of a request missing the

以下のセクションは本書では定義された各WantBackについて説明します。 証拠記録のための各WantBackは要求に存在しているように証拠記録でカバーされたオブジェクトのために対応するWantBackを必要とします。 要求の取り逃がすことを受け取り次第

Wallace                     Standards Track                     [Page 6]

RFC 5276               Evidence Records via SCVP             August 2008

SCVP2008年8月を通したウォレスStandards Track[6ページ]RFC5276Evidence Records

   corresponding WantBack for the object covered by a requested evidence
   record, the server MUST indicate wantBackUnsatisfied in the
   ReplyStatus.  Clients MAY ignore evidence record WantBacks when the
   WantBack for the corresponding object is not present.

要求された証拠でカバーされたオブジェクトのための対応するWantBackは記録して、サーバはReplyStatusでwantBackUnsatisfiedを示さなければなりません。 対応するオブジェクトのためのWantBackが存在していないとき、クライアントは証拠の記録的なWantBacksを無視するかもしれません。

5.1.  Evidence Record for a Complete Certification Path

5.1. 完全な証明経路のための証拠記録

   The id-swb-ers-best-cert-path OID is used to request an evidence
   record for a complete certification path.  It is used in conjunction
   with the id-swb-best-cert-path OID.  Requests containing id-swb-ers-
   best-cert-path as a WantBack MUST also contain id-swb-best-cert-path.
   Responses containing id-swb-ers-best-cert-path MUST also contain id-
   swb-best-cert-path.

イドのswb-ersの最も良い本命道のOIDは、完全な証明経路のための証拠記録を要求するのに使用されます。 それはイドのswbの最も良い本命道のOIDに関連して使用されます。 -イド-swb-ersを含んでいて、また、WantBackとしての最も良い本命道がイドのswbの最も良い本命道を含まなければならないよう要求します。 また、含む中でイドswb-ers本命道最も良い応答はイドのswbの最も良い本命道を含まなければなりません。

   An SCVP server may maintain evidence records for complete
   certification paths, i.e., certification paths containing all
   certificates from end entity to trust anchor.  The evidence record
   MUST be calculated over the CertBundle returned via the id-swb-best-
   cert-path replyWantBack.  In such cases, a signature within the
   archived data object may be verified using an end entity certificate
   returned via SCVP.  The end entity certificate can be verified using
   SCVP using a request containing id-swb-ers-best-cert-path, id-swb-
   best-cert-path, id-swb-pkc-revocation-info, and id-swb-ers-
   revocation-info.

SCVPサーバは完全な証明経路のための証拠記録を保守するかもしれません、すなわち、終わりの実体から信頼まですべての証明書を含む証明経路が投錨されます。 CertBundleの上でイド-swbベストで本命道のreplyWantBackを返して証拠記録について計算しなければなりません。 そのような場合、格納されたデータ・オブジェクトの中の署名は、SCVPを通して返された終わりの実体証明書を使用することで確かめられるかもしれません。 イド-swbイドのswb-ersの最も良い本命道、最も良い本命道、イドswb-pkc取消しインフォメーション、およびイドswb-ersを含む要求を使用することでSCVPを使用することで終わりの実体証明書について確かめることができる、-、取消しインフォメーション。

5.2.  Evidence Record for a Partial Certification Path

5.2. 分割認定経路のための証拠記録

   The id-swb-ers-partial-cert-path OID is used to request an evidence
   record for a partial certification path.  It is used in conjunction
   with the id-swb-partial-cert-path OID.  Requests containing id-swb-
   ers-partial-cert-path as a WantBack MUST also contain id-swb-partial-
   cert-path.  Responses containing id-swb-ers-partial-cert-path MUST
   also contain id-swb-partial-cert-path.

イドのswb-ersの部分的な本命道のOIDは、分割認定経路のための証拠記録を要求するのに使用されます。 それはイドのswbの部分的な本命道のOIDに関連して使用されます。 また、WantBackがイド-swbを含まなければならないのでイドのswb- ersの部分的な本命道を含む要求、-、部分的である、-、本命道。 また、イドのswb-ersの部分的な本命道を含む応答はイドのswbの部分的な本命道を含まなければなりません。

   As an alternative to relying on SCVP to obtain evidence records for
   end entity certificates, the certificate could be included in the
   archived data object(s) submitted to an LTA.  In such cases, a
   signature within the archived data object may be verified using the
   included end entity certificate, which is protected by the evidence
   record covering the archived data object, including the certificate.
   The end entity certificate can be verified using SCVP using a request
   containing id-swb-partial-cert-path, id-swb-ers-partial-cert-path,
   id-swb-pkc-revocation-info, and id-swb-ers-revocation-info.  Unlike
   the partial certification path, the revocation information includes
   material that can be used to determine the status of the end entity
   certificate.

終わりの実体証明書のための証拠記録を得るためにSCVPを当てにすることに代わる手段として、LTAに提出された格納されたデータ・オブジェクトに証明書を含むことができました。 そのような場合、格納されたデータ・オブジェクトの中の署名は格納されたデータ・オブジェクトをカバーする証拠記録によって保護される含まれている終わりの実体証明書を使用することで確かめられるかもしれません、証明書を含んでいて。 イドのswbの部分的な本命道、イドのswb-ersの部分的な本命道、イドswb-pkc取消しインフォメーション、およびイドswb-ers取消しインフォメーションを含む要求を使用することでSCVPを使用することで終わりの実体証明書について確かめることができます。 部分的な証明経路と異なって、取消し情報は終わりの実体証明書の状態を決定するのに使用できる材料を含んでいます。

Wallace                     Standards Track                     [Page 7]

RFC 5276               Evidence Records via SCVP             August 2008

SCVP2008年8月を通したウォレスStandards Track[7ページ]RFC5276Evidence Records

   By maintaining an evidence record for a partial certification path,
   SCVP servers can achieve greater storage efficiency.

分割認定経路のための証拠記録を保守することによって、SCVPサーバは、より大きい充てん率を実現できます。

5.3.  Evidence Record for a Public Key Certificate

5.3. 公開鍵証明書のための証拠記録

   The id-swb-ers-pkc-cert OID is used to request an evidence record for
   an individual public key certificate.  It is used in conjunction with
   the id-swb-pkc-cert OID.  Requests containing id-swb-ers-pkc-cert as
   a WantBack MUST also contain id-swb-pkc-cert.  Responses containing
   id-swb-ers-pkc-cert MUST also contain id-swb-pkc-cert.

イドswb-ers-pkc本命OIDは、個々の公開鍵証明書のための証拠記録を要求するのに使用されます。 それはイドswb-pkc本命OIDに関連して使用されます。 また、WantBackとしてイドswb-ers-pkc本命を含む要求はイドswb-pkc本命を含まなければなりません。 また、イドswb-ers-pkc本命を含む応答はイドswb-pkc本命を含まなければなりません。

   SCVP servers may maintain evidence records for individual
   certificates.  This enables clients to omit the signer's certificate
   from archived data object(s) submitted to an LTA.  In such cases, a
   signature within the archived data object may be verified using an
   end entity certificate returned via SCVP.  The end entity certificate
   can be verified using SCVP using a request containing id-swb-pkc-
   cert, id-swb-ers-pkc-cert, id-swb-partial-cert-path, id-swb-ers-
   partial-cert-path, id-swb-pkc-revocation-info, and id-swb-ers-
   revocation-info.

SCVPサーバは個々の証明書のための証拠記録を保守するかもしれません。 これは、クライアントがLTAに提出された格納されたデータ・オブジェクトからの署名者の証明書を省略するのを可能にします。 そのような場合、格納されたデータ・オブジェクトの中の署名は、SCVPを通して返された終わりの実体証明書を使用することで確かめられるかもしれません。 イド-swb-ersイド-swb-pkc本命、イドswb-ers-pkc本命、イドのswbの部分的な本命道、部分的な本命道、イドswb-pkc取消しインフォメーション、およびイドswb-ersを含む要求を使用することでSCVPを使用することで終わりの実体証明書について確かめることができる、-、取消しインフォメーション。

5.4.  Evidence Record for Revocation Information

5.4. 取消し情報のための証拠記録

   The id-swb-ers-revocation-info OID is used to request evidence
   records for a set of revocation information.  It is used in
   conjunction with the id-swb-revocation-info OID.  Requests containing
   id-swb-ers-revocation-info as a WantBack MUST also contain id-swb-
   revocation-info.  Responses containing id-swb-ers-revocation-info
   MUST also contain id-swb-revocation-info.  A sequence of evidence
   records is returned, with one evidence record provided for each
   element in id-swb-revocation-info.

イドswb-ers取消しインフォメーションOIDは、1セットの取消し情報のための証拠記録を要求するのに使用されます。 それはイドswb取消しインフォメーションOIDに関連して使用されます。 また、WantBackがイド-swbを含まなければならないのでイドswb-ers取消しインフォメーションを含む要求、-、取消しインフォメーション。 また、イドswb-ers取消しインフォメーションを含む応答はイドswb取消しインフォメーションを含まなければなりません。 証拠記録の系列はイドswb取消しインフォメーションの各要素に1つの証拠記録を提供している状態で返されます。

     EvidenceRecords ::= SEQUENCE SIZE (1..MAX) OF EvidenceRecord

EvidenceRecords:、:= EvidenceRecordの系列サイズ(1..MAX)

   An SCVP server may maintain evidence records for revocation
   information.  Revocation information may be provided in the form of
   CRLs or Online Certificate Status Protocol (OCSP) responses.
   Cumulative CRLs may be generated for archiving to simplify evidence
   record maintenance.

SCVPサーバは取消し情報のための証拠記録を保守するかもしれません。 CRLsかOnline Certificate Statusプロトコル(OCSP)応答の形に取消し情報を提供するかもしれません。 累積しているCRLsは証拠記録メインテナンスを簡素化する格納のために生成されるかもしれません。

5.5.  Evidence Record for Any replyWantBack

5.5. どんなreplyWantBackのための証拠記録

   An SCVP server may maintain evidence records for additional types of
   information that can be returned using the wantBack mechanism, e.g.,
   attribute certificate information.  The id-swb-ers-all OID provides a
   shorthand means for clients to request evidence records for all
   information returned via the replyWantBacks field.  Since id-swb-ers-
   all can result in the return of multiple evidence records in the

SCVPサーバはwantBackメカニズムを使用することで返すことができる追加タイプの情報のための証拠記録を保守するかもしれません、例えば、属性証明書情報。 イドswb-ers、すべて、OIDはクライアントがすべての情報のための記録がreplyWantBacks分野を通って戻ったという証拠を要求する手段を速記に提供します。 以来、イド-swb-ersはすべて、証拠が記録する倍数の復帰をもたらすことができます。

Wallace                     Standards Track                     [Page 8]

RFC 5276               Evidence Records via SCVP             August 2008

SCVP2008年8月を通したウォレスStandards Track[8ページ]RFC5276Evidence Records

   response, a mechanism is needed to associate an evidence record with
   the type of information covered by the evidence record.  The
   EvidenceRecordWantBacks structure provides a flexible means of
   conveying an evidence record for different types of information.

応答、メカニズムが、証拠記録でカバーされる情報の種類に証拠記録を関連づけるのに必要です。 EvidenceRecordWantBacks構造は異なったタイプの情報のための証拠記録を伝える柔軟な手段を提供します。

   EvidenceRecordWantBack ::= SEQUENCE
   {
       targetWantBack    OBJECT IDENTIFIER,
       evidenceRecord    EvidenceRecord OPTIONAL
   }

EvidenceRecordWantBack:、:= 系列targetWantBackオブジェクト識別子で、evidenceRecord EvidenceRecord任意です。

   EvidenceRecordWantBacks ::=
       SEQUENCE SIZE (1..MAX) OF EvidenceRecordWantBack

EvidenceRecordWantBacks:、:= EvidenceRecordWantBackの系列サイズ(1..MAX)

   EvidenceRecordWantBacks is a SEQUENCE OF EvidenceRecordWantBack
   structures.  The targetWantBack field indicates the type of
   replyWantBack covered by the associated EvidenceRecord.  The
   evidenceRecord field, if present, contains an EvidenceRecord
   structure calculated over the replyWantBack indicated by the
   targetWantBack field.  Where EvidenceRecordWantBacks is used, there
   MUST be a one-to-one correspondence between other replyWantBack
   objects and objects in the EvidenceRecordWantBacks collection.  If a
   server does not have an EvidenceRecord for a particular replyWantBack
   object, an EvidenceRecordWantBack with the evidenceRecord field
   absent should be included in the EvidenceRecordWantBacks collection.

EvidenceRecordWantBacksはSEQUENCE OF EvidenceRecordWantBack構造です。 targetWantBack分野は関連EvidenceRecordでカバーされたreplyWantBackのタイプを示します。 存在しているなら、evidenceRecord分野はtargetWantBack分野によって示されたreplyWantBackの上で計算されたEvidenceRecord構造を含んでいます。 EvidenceRecordWantBacksが使用されているところに、EvidenceRecordWantBacks収集には他のreplyWantBackオブジェクトとオブジェクトとの1〜1つの通信があるに違いありません。 サーバに特定のreplyWantBackオブジェクトのためのEvidenceRecordがないなら、evidenceRecord分野が欠けているEvidenceRecordWantBackはEvidenceRecordWantBacks収集に含まれるべきです。

5.6.  Partial Certification Path

5.6. 分割認定経路

   The id-swb-partial-cert-path is an alternative to id-swb-best-cert-
   path.  This is the only OID defined in this document for which an
   EvidenceRecord is not returned in the response.  For efficiency, SCVP
   servers that maintain evidence records for certification paths may
   only do so for partial paths instead of maintaining one or more paths
   for each end entity certificate.

イドのswbの部分的な本命道はイド-swb最も良い本命道への代替手段です。 これはEvidenceRecordが応答で返されない本書では定義された唯一のOIDです。 効率のために、証明経路のための証拠記録を保守するSCVPサーバはそうそれぞれの終わりの実体証明書あたり1つ以上の経路を維持することの代わりに部分的な経路にするだけであるかもしれません。

   SCVP clients can include id-swb-partial-cert-path in a request when a
   partial certification path is required.  This would typically be
   included along with id-swb-ers-partial-cert-path to account for the
   fact that some SCVP servers only produce evidence records for partial
   paths for storage and computational efficiency reasons.  In such
   cases, a separate evidence record may be available for the end entity
   certificate by including id-swb-pkc-cert and id-swb-ers-pkc-cert in
   the request.

分割認定経路が必要であるときに、SCVPクライアントは要求でイドのswbの部分的な本命道を入れることができます。 これは、いくつかのSCVPサーバがストレージと計算効率理由で部分的な経路のための証拠記録を作り出すだけであるという事実を説明するためにイドのswb-ersの部分的な本命道と共に通常含まれているでしょう。 そのような場合、別々の証拠記録は、要求にイドswb-pkc本命とイドswb-ers-pkc本命を含んでいることによって、終わりの実体証明書に利用可能であるかもしれません。

Wallace                     Standards Track                     [Page 9]

RFC 5276               Evidence Records via SCVP             August 2008

SCVP2008年8月を通したウォレスStandards Track[9ページ]RFC5276Evidence Records

6.  Security Considerations

6. セキュリティ問題

   For security considerations specific to SCVP, see [RFC5055].  For
   security considerations specific to ERS, see [RFC4998].

SCVPに特定のセキュリティ問題に関しては、[RFC5055]を見てください。 ERSに特定のセキュリティ問題に関しては、[RFC4998]を見てください。

   The signature on the SCVP response containing one or more ERS
   structures must be verified using a public key trusted by the relying
   party.  The response may contain trust anchors used to verify
   interior layers of an ERS structure.  The trust anchors are protected
   by the SCVP server's signature covering the response.  The relying
   party may elect to use the trust anchors conveyed in the response or
   ignore the trust anchors in favor of trust anchors retrieved out of
   band.  Relying parties SHOULD ignore trust anchors contained in
   unsigned SCVP responses.

信用パーティーによって信じられた公開鍵を使用することで1つ以上のERS構造を含むSCVP応答の署名について確かめなければなりません。 応答はERS構造の内部の層について確かめるのに使用される信頼アンカーを含むかもしれません。 信頼アンカーは応答をカバーするSCVPサーバの署名で保護されます。 信用パーティーは、応答で運ばれた信頼アンカーを使用するか、またはバンドから救済された信頼アンカーを支持して信頼アンカーを無視するのを選ぶかもしれません。 SHOULDが無視する信用パーティーは未署名のSCVP応答に含まれたアンカーを信じます。

7.  References

7. 参照

7.1.  Normative References

7.1. 引用規格

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

[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

   [RFC4998]     Gondrom, T., Brandner, R., and U. Pordesch, "Evidence
                 Record Syntax (ERS)", RFC 4998, August 2007.

[RFC4998] GondromとT.とBrandner、R.とU.Pordesch、「証拠の記録的な構文(ERS)」、RFC4998、2007年8月。

   [RFC5055]     Freeman, T., Housley, R., Malpani, A., Cooper, D., and
                 W. Polk, "Server-Based Certificate Validation Protocol
                 (SCVP)", RFC 5055, December 2007.

[RFC5055] フリーマン、T.、Housley、R.、Malpani、A.、クーパー、D.、およびW.ポーク、「サーバベースの証明書合法化プロトコル(SCVP)」、RFC5055 2007年12月。

7.2.  Informative References

7.2. 有益な参照

   [LTANS-LTAP]  Jerman-Blazic, A., Sylvester, P., and C. Wallace,
                 "Long-term Archive Protocol (LTAP)", Work in Progress,
                 February 2008.

2008年2月の[LTANS-LTAP]Jerman-BlazicとA.とシルベスター、P.とC.ウォレス、「長期のアーカイブプロトコル(LTAP)」処理中の作業。

Wallace                     Standards Track                    [Page 10]

RFC 5276               Evidence Records via SCVP             August 2008

SCVP2008年8月を通したウォレスStandards Track[10ページ]RFC5276Evidence Records

Appendix A.  ASN.1 Module

付録A.ASN.1モジュール

   The following ASN.1 module defines object identifiers used to
   identify six new forms of SCVP WantBacks and three new structures.
   EvidenceRecordWantBack and EvidenceRecordWantBacks are used in
   conjunction with the id-swb-ers-all WantBack to correlate evidence
   records with WantBacks.  EvidenceRecords is used in conjunction with
   the id-swb-ers-revocation-info WantBack to return evidence records
   for individual revocation information objects.

以下のASN.1モジュールはSCVP WantBacksと3つの新しい構造の6つの新しいフォームを特定するのに使用されるオブジェクト識別子を定義します。 に関連してEvidenceRecordWantBackとEvidenceRecordWantBacksが使用されている、イドswb-ers、すべて、関連するWantBackはWantBacksと共に記録を証明します。 EvidenceRecordsは、個々の取消し情報オブジェクトのための証拠記録を返すのにイドswb-ers取消しインフォメーションWantBackに関連して使用されます。

   LTANS-SCVP-EXTENSION
   { iso(1) identified-organization(3) dod(6) internet(1)
      security(5) mechanisms(5) ltans(11) id-mod(0) id-mod-ers-scvp(5)
      id-mod-ers-scvp-v1(1) }

LTANS-SCVP-拡大iso(1)の特定された組織(3)のdod(6)インターネット(1)セキュリティ(5)メカニズム(5)ltans(11)イドモッズ(0)のイドモッズers-scvp(5)のイドモッズ風のers-scvp-v1(1)

   DEFINITIONS IMPLICIT TAGS ::=
   BEGIN

定義、内在しているタグ:、:= 始まってください。

   IMPORTS

輸入

   id-swb
   FROM SCVP
   { iso(1) identified-organization(3) dod(6) internet(1)
       security(5) mechanisms(5) pkix(7) id-mod(0) 21 }

イド-swb FROM SCVPiso(1)の特定された組織(3)dod(6)のインターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)21

   EvidenceRecord
   FROM ERS
   {iso(1) identified-organization(3) dod(6) internet(1)
       security(5) mechanisms(5) ltans(11) id-mod(0) id-mod-ers88(2)
       id-mod-ers88-v1(1) };

EvidenceRecord FROM ERSのiso(1)の特定された組織(3)dod(6)のインターネット(1)セキュリティ(5)メカニズム(5)ltans(11)イドモッズ風の(0)イド-mod-ers88(2)イド-mod-ers88-v1(1)。

   id-swb-partial-cert-path        OBJECT IDENTIFIER ::= {id-swb 15 }

イドのswbの部分的な本命道のOBJECT IDENTIFIER:、:= イド-swb15

   id-swb-ers-pkc-cert             OBJECT IDENTIFIER ::= {id-swb 16 }
   id-swb-ers-best-cert-path       OBJECT IDENTIFIER ::= {id-swb 17 }
   id-swb-ers-partial-cert-path    OBJECT IDENTIFIER ::= {id-swb 18 }
   id-swb-ers-revocation-info      OBJECT IDENTIFIER ::= {id-swb 19 }
   id-swb-ers-all                  OBJECT IDENTIFIER ::= {id-swb 20 }

イドswb-ers-pkc本命OBJECT IDENTIFIER:、:= イド-swb16のイドのswb-ersの最も良い本命道のOBJECT IDENTIFIER:、:= イド-swb17のイドのswb-ersの部分的な本命道のOBJECT IDENTIFIER:、:= イド-swb18、イドswb-ers取消しインフォメーションOBJECT IDENTIFIER:、:= イド-swb19、イドswb-ers、すべて、OBJECT IDENTIFIER:、:= イド-swb20

   EvidenceRecordWantBack ::= SEQUENCE
   {
       targetWantBack    OBJECT IDENTIFIER,
       evidenceRecord    EvidenceRecord OPTIONAL
   }

EvidenceRecordWantBack:、:= 系列targetWantBackオブジェクト識別子で、evidenceRecord EvidenceRecord任意です。

Wallace                     Standards Track                    [Page 11]

RFC 5276               Evidence Records via SCVP             August 2008

SCVP2008年8月を通したウォレスStandards Track[11ページ]RFC5276Evidence Records

   EvidenceRecordWantBacks ::=
       SEQUENCE SIZE (1..MAX) OF EvidenceRecordWantBack

EvidenceRecordWantBacks:、:= EvidenceRecordWantBackの系列サイズ(1..MAX)

   EvidenceRecords ::= SEQUENCE SIZE (1..MAX) OF EvidenceRecord

EvidenceRecords:、:= EvidenceRecordの系列サイズ(1..MAX)

   END

終わり

Author's Address

作者のアドレス

   Carl Wallace
   Cygnacom Solutions
   Suite 5200
   7925 Jones Branch Drive
   McLean, VA  22102

スイート5200 7925ジョーンズ支店のDriveマクリーン、カールウォレスCygnacom Solutionsヴァージニア 22102

   EMail: cwallace@cygnacom.com

メール: cwallace@cygnacom.com

Wallace                     Standards Track                    [Page 12]

RFC 5276               Evidence Records via SCVP             August 2008

SCVP2008年8月を通したウォレスStandards Track[12ページ]RFC5276Evidence Records

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The IETF Trust (2008).

IETFが信じる著作権(C)(2008)。

   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.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   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, THE IETF TRUST 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.

このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。

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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   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.

IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   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-ipr@ietf.org のIETFに情報を記述してください。

Wallace                     Standards Track                    [Page 13]

ウォレス標準化過程[13ページ]

一覧

 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 

スポンサーリンク

PostgreSQLでERROR: duplicate key value violates unique constraint "hoge_pkey" DETAIL: Key (id)=(10) already exists.と出る場合

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

上に戻る