[要約] 要約：RFC 7681は、中等教育の成績証明書を電子メールで交換するためのプロトコルを提案しています。 目的：このRFCの目的は、学校間での成績証明書の効率的な交換を可能にし、学生の移転や進学に関連する手続きを簡素化することです。
Independent Submission J. Davin
Request for Comments: 7681 October 2015
Category: Informational
ISSN: 2070-1721
Email Exchange of Secondary School Transcripts
中等学校成績証明書のメール交換
Abstract
概要
A common format simplifies exchange of secondary school academic transcripts via electronic mail. Existing standards are applied to prevent unauthorized alteration of transcript content and to deliver transcripts directly and securely from each student to his or her chosen recipients. By eliminating third-party intervention and surveillance, the defined protocol better protects student privacy and independence than does current practice.
共通フォーマットは、電子メールによる中等学校の成績証明書の交換を簡素化します。筆記録コンテンツの不正な変更を防止し、筆記録を各学生から選択した受信者に直接かつ安全に配信するために、既存の基準が適用されます。サードパーティの介入と監視を排除することにより、定義されたプロトコルは、現在の慣行よりも学生のプライバシーと独立性をよりよく保護します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7681.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7681で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Design Motivation . . . . . . . . . . . . . . . . . . . . . . 6
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Student and Originator . . . . . . . . . . . . . . . . . 8
3.1.1. Transcript Requests . . . . . . . . . . . . . . . . . 9
3.2. Student and Recipient . . . . . . . . . . . . . . . . . . 10
4. Transcript Content . . . . . . . . . . . . . . . . . . . . . 13
4.1. School Transcript Preface . . . . . . . . . . . . . . . . 17
4.2. Computational School Transcript . . . . . . . . . . . . . 17
4.3. Display School Transcript . . . . . . . . . . . . . . . . 20
5. Signed School Transcript . . . . . . . . . . . . . . . . . . 21
6. Transcript Transmission . . . . . . . . . . . . . . . . . . . 24
6.1. Encrypted Format . . . . . . . . . . . . . . . . . . . . 27
6.2. Encrypted and Signed Format . . . . . . . . . . . . . . . 28
6.3. Encrypted File Format . . . . . . . . . . . . . . . . . . 30
6.4. Traditional Inline Format . . . . . . . . . . . . . . . . 33
7. Security Considerations . . . . . . . . . . . . . . . . . . . 34
7.1. Originator Private Key . . . . . . . . . . . . . . . . . 35
7.2. Originator Public Key . . . . . . . . . . . . . . . . . . 35
7.3. Originator Certification . . . . . . . . . . . . . . . . 35
7.4. Recipient Public Key . . . . . . . . . . . . . . . . . . 35
7.5. Secure Clients . . . . . . . . . . . . . . . . . . . . . 36
7.6. Automatic Replies . . . . . . . . . . . . . . . . . . . . 36
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
8.1. Registration of Eesst-Version Header . . . . . . . . . . 37
8.2. Registration of Organization Header . . . . . . . . . . . 37
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
9.1. Normative References . . . . . . . . . . . . . . . . . . 38
9.2. Informative References . . . . . . . . . . . . . . . . . 38
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 40
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 40
Traditional, paper-based communication of individual student records protects the rights and interests of all stakeholders -- the secondary school officials who curate student records, the students who are both the subjects and distributors of their own individual records, and the college admission officers, prospective employers, and others who, with the permission of individual students, receive and review such records. In the traditional process, when a graduating student applies for employment or admission to an institution of higher learning, she asks the guidance counselor at her secondary school for a transcript of her academic achievements to support her application. In response, the guidance counselor prepares a paper record of that student's achievements and presents it to her so that she might forward that transcript to whomever she pleases. In order to prevent forgery of academic transcripts, the paper record presented to the student often includes various marks of its authenticity, such as an imprint of the school seal or the signature of an authorized school official. In order to prevent unauthorized alteration of transcript content, the prepared document is sometimes presented to the student inside a sealed postal envelope that cannot easily be opened without detection -- perhaps aided by tamper-proof tape, signed envelope flaps, or even imprinted wax seals. The integrity of the envelope's physical seal assures the recipient that its contents have not been altered in transit; seals and signatures affixed to the enclosed document assure the recipient of the transcript's legitimacy. The student's privacy is assured by her ability to forward the sealed transcript to whomever she pleases without the knowledge of or further consultation with the school.
個々の生徒の記録の従来の紙ベースのコミュニケーションは、すべての利害関係者（生徒の記録をキュレーションする中等学校の職員、自分の個人の記録の主題と配布者の両方である生徒、および大学入試担当者）の権利と利益を保護します。将来の雇用主、および個々の学生の許可を得て、そのような記録を受け取り、検討する他の雇用主。従来のプロセスでは、卒業生が高等教育機関への就職または入学を申請する際、彼女は中等学校の指導カウンセラーに彼女の学業成績の筆記録を求め、彼女の申請をサポートします。それに応じて、ガイダンスカウンセラーはその生徒の成績の紙の記録を作成し、彼女に提示して、彼女が好きな人にその筆記録を転送できるようにします。学業成績証明書の偽造を防ぐために、学生に提示される紙の記録には、学校の印鑑の印や認可された学校職員の署名など、その真正性のさまざまなマークが含まれていることがよくあります。筆記録コンテンツの不正な変更を防ぐために、準備されたドキュメントは、検出なしでは簡単に開けられない封印された封筒の中で学生に提示される場合があります-おそらく改ざん防止テープ、署名された封筒のフラップ、または刻印されたワックスのシールでさえ助けられます。封筒の物理的なシールの完全性は、その内容が輸送中に変更されていないことを受信者に保証します。同封のドキュメントに添付されたシールと署名は、筆記録の正当性を受信者に保証します。生徒のプライバシーは、学校の知識がなくても、または学校とさらに協議することなく、封印された筆記録を好きな人に転送する能力によって保証されます。
+++
/ \
/\ Digital Transcript / \
/ \ Via Web or Database Connection / \
/ 88 \ / \
/ 88 \ \\ // | College |
/ \ (---) +-------------->> | |
| School | +--------->> (###) +---------+
| | | |
+--------+ <<... | | Copies of Digital Transcript
School Guidance Dept \@| |@ Via Web or Database Connection
| |
+ + +-------+ +++
+------------>> / \
Third-Party Processor / \
Monitors and Controls / \
Student Communication / \
| College |
| |
+---------+
Figure 1: Corrupted Model for Exchanging Secondary School Transcripts
図1：中等学校の成績証明書を交換するための破損したモデル
While the traditional process of distributing academic transcripts admirably protects student privacy and prerogatives, that process also requires manual effort from the school staff for the preparation of each transcript. On the premise of reducing that effort, some school officials have gratuitously misapplied technology in a way that guts student privacy and effectively excludes students from their own business. Figure 1 illustrates an increasingly common aberration. Rather than adopting standardized, readily available technology to protect the integrity of transmitted student data -- as it had once been protected by their own signatures on sealed envelopes -- school officials interpose themselves (or their agents) between students and transcript recipients, claiming falsely that no other approach adequately assures the confidentiality, origin, and integrity of transcript content or the reliability of transcript transmission. By introducing the role of "third-party processor" in Figure 1, educators disrupt what should be private, bilateral relationships between students and their chosen correspondents, implicitly denying the legitimacy of any technical means by which a student might manage and secure his/her own communication.
成績証明書を配布する従来のプロセスは生徒のプライバシーと特権を見事に保護しますが、そのプロセスでは、各成績証明書の準備のために学校のスタッフによる手動の作業も必要です。その努力を減らすことを前提に、一部の学校関係者は、生徒のプライバシーを守り、生徒を自分のビジネスから事実上排除するような方法で、不当にテクノロジーを悪用しています。図1は、ますます一般的な収差を示しています。学校の職員は、封印された封筒の独自の署名によって保護されていたため、送信された生徒のデータの整合性を保護するために、標準化されたすぐに利用できるテクノロジーを採用するのではなく、生徒と筆記録の受信者の間に自分自身（またはその代理人）を介在させ、誤って主張します他の方法では、筆記録コンテンツの機密性、出所、完全性、または筆記録送信の信頼性を適切に保証しない。教育者は、図1で「サードパーティプロセッサ」の役割を導入することにより、学生と選択した特派員の間のプライベートな双方向の関係を混乱させ、学生が自分の管理とセキュリティを確保する技術的手段の正当性を暗黙のうちに否定します。独自のコミュニケーション。
By coercing students into a false choice between surrendering their privacy or accepting the limitations of a neglected, largely manual system, educators and allied service providers gain significant new benefits at student expense. Among these benefits is the creation of an otherwise unneeded educational services industry to mediate communication between students and transcript recipients -- communication that, by the most natural operation of the Internet, would otherwise be end-to-end. A second consequence of coerced mediation is that the mediators gain unfettered control over school records that would otherwise be private and often protected by law. A third consequence of coerced mediation is that mediators can harvest candid data on student behavior outside the secondary school domain. Even the most basic information about college and employment applications, successful or not, individual or in the aggregate, can have significant value for secondary school officials, college administrators, employers, and general marketing professionals. Moreover, although such data is historically private, it is also more valuable and legally less well protected than internal secondary school records.
プライバシーを放棄するか、または無視された、主に手動のシステムの制限を受け入れるかという誤った選択を学生に強いることにより、教育者と関連サービスプロバイダーは学生の費用で重要な新しい利益を得ることができます。これらの利点の中には、学生と筆記録の受信者の間のコミュニケーションを仲介するために、そうでなければ不要な教育サービス産業の作成があります-インターネットの最も自然な操作によって、そうでなければエンドツーエンドになるコミュニケーション。強制された調停の第2の結果は、調停者が学校の記録を自由に管理できるようになることです。強制調停の3番目の結果は、調停者が中等学校のドメイン外の生徒の行動に関する率直なデータを収集できることです。カレッジと就職の申し込みに関する最も基本的な情報でさえ、個人か全体かを問わず、中等学校の職員、大学の管理者、雇用主、および一般的なマーケティングの専門家に大きな価値があります。さらに、そのようなデータは歴史的には非公開ですが、中等学校の内部記録よりも価値が高く、法的に十分に保護されていません。
Mediated transcript distribution vitiates student privacy while endowing school bureaucrats and their confederates with undeserved privilege, but these political concessions are utterly unnecessary to automated transcript distribution. As suggested by Figure 2, the political concessions intrinsic to mediated transcript exchange can be largely eliminated by the most straightforward automation of the traditional transcript process.
仲介された筆記録の配布は学生のプライバシーを侵害し、学校の官僚とその同盟者に不当な特権を与えますが、これらの政治的譲歩は自動化された筆記録の配布にはまったく不要です。図2で示唆されているように、仲介されたトランスクリプト交換に固有の政治的譲歩は、従来のトランスクリプトプロセスを最も簡単に自動化することで大幅に排除できます。
This memo specifies a common format for exchanging secondary school academic transcripts via electronic mail. Because the defined format supports digital signature of transcripts by their originator, a student cannot fabricate or alter transcript information provided by school officials. Because the described format supports encrypted transmission of school transcripts, the distribution of each student's information can remain private and under his or her control. Because the format supports asymmetric cryptography, the origin and integrity of received transcripts can be verified independently by the recipient; confidential content can be independently recovered by an intended recipient while remaining protected from unauthorized access. Because the Internet email protocol provides fail-safe delivery, transcripts are reliably delivered to their intended recipients, and the sending student is directly notified of any exceptions. No centralized, trusted authority is needed to mediate communication between students, transcript originators, or transcript recipients. Thus, a student's need for an authoritative record of his education cannot be exploited to restrict or monitor his/her free and private interactions with colleges, employers, or others. Students can reclaim control over their own personal information and their relationships with prospective employers and admissions officers; students can prevent surreptitious harvesting of information about their affairs. Last but not least, specialized software is not required by most participants in the school transcript exchange protocol: the needs of all students and many transcript recipients can be met by existing, standards-based, secure email clients.
このメモは、電子メールを介して中等学校の成績証明書を交換するための一般的な形式を指定します。定義された形式は、作成者による筆記録のデジタル署名をサポートしているため、生徒は学校職員が提供する筆記録情報を作成または変更することはできません。説明されている形式は学校の筆記録の暗号化された送信をサポートしているため、各学生の情報の配布は非公開のままにして、生徒の管理下に置くことができます。この形式は非対称暗号化をサポートしているため、受信したトランスクリプトの出所と整合性は、受信者が個別に確認できます。機密コンテンツは、不正なアクセスから保護されたまま、意図した受信者が個別に復元できます。インターネット電子メールプロトコルはフェイルセーフ配信を提供するため、トランスクリプトは確実に目的の受信者に配信され、送信側の学生には例外が直接通知されます。学生、筆記録者、筆記録受信者間のコミュニケーションを仲介するために、集中化された信頼できる機関は必要ありません。したがって、彼の教育の信頼できる記録に対する学生の必要性を利用して、大学、雇用主、またはその他との彼/彼女の自由な私的相互作用を制限または監視することはできません。学生は、自分の個人情報、および将来の雇用主や入学担当官との関係を管理することができます。学生は、自分の業務に関する情報の不正な収集を防ぐことができます。最後に重要なことですが、学校の筆記録交換プロトコルのほとんどの参加者は特殊なソフトウェアを必要としません。すべての生徒と多くの筆記録受信者のニーズは、既存の標準ベースの安全な電子メールクライアントで満たすことができます。
+++
/ \
/\ Digitally Signed Transcript / \
/ \ Via CD-ROM, Secure Email, etc. / \
/ 88 \ / \
/ 88 \ --- | College |
/ \ (0 0) +-------------->> | |
| School | +--------->> ( - ) +---------+
| | | | Copies of
+--------+ | | Digitally Signed Transcript
School Guidance Dept | | Via Secure Email, CD-ROM, etc.
| |
| | +-------+ +++
8 8 +------------>> / \
Student / \
Privately and Autonomously / \
Forwards Digitally Signed Transcript / \
| College |
| |
+---------+
Figure 2: Traditional Model for Exchanging Secondary School Transcripts
図2：中等学校の成績証明書を交換するための従来のモデル
The acronym EESST (Email Exchange of Secondary School Transcripts) names the format and methods defined here for securely conveying student academic records under student control. Requirements for implementors of this specification are expressed here using a keyword vocabulary [RFC2119] that is widely understood within the Internet community.
頭字語EESST（中等学校成績証明書の電子メール交換）は、生徒の管理下で生徒の学業成績を安全に伝えるためにここで定義されている形式と方法を示しています。この仕様の実装者の要件は、インターネットコミュニティ内で広く理解されているキーワードボキャブラリー[RFC2119]を使用してここに表現されています。
Implicit in any protocol definition is some assignment of functions to the various protocol participants. When those participants are administratively independent one from another, binding assignments of protocol function -- which might otherwise seem purely technical choices -- are politically significant. For the sake of transparency, this protocol specification explicitly reckons the political consequences of its implicit design choices.
プロトコル定義で暗黙的に行われるのは、さまざまなプロトコル参加者への関数の割り当てです。それらの参加者が管理上互いに独立している場合、プロトコル機能のバインド割り当て（そうでなければ純粋に技術的な選択に見えるかもしれません）は政治的に重要です。透明性のために、このプロトコル仕様では、暗黙的な設計選択の政治的影響を明確に考慮しています。
Preparation and delivery of secondary school transcripts most affects the interests of individual students. After all, the process is entirely motivated by a student's need to certify his or her personal academic achievements as evidence of merit for employment, higher education, or other social advancement or reward. Accordingly, individual student needs properly dominate the design of a common system for transcript exchange. Because a secondary school transcript certifies a student's personal merit, students need transcript documents that are credible to recipients -- for which the origin and integrity of transcript content is assured. Because a school transcript records personal information about an individual student, student privacy is paramount: control of transcript distribution must be closely held by the individual student, and each student must be able to protect the confidentiality of his or her transcript in transit.
中等学校の成績証明書の作成と配信は、個々の生徒の興味に最も影響します。結局のところ、このプロセスは、就職、高等教育、またはその他の社会的進歩または報酬のメリットの証拠としての個人的な学業成績を証明する学生のニーズによって完全に動機付けられています。したがって、個々の学生は筆記録交換のための共通システムの設計を適切に支配する必要があります。中等学校の筆記録は生徒の個人的なメリットを証明するため、受講者に信頼できる筆記録ドキュメントが必要です。これにより、筆記録コンテンツの出所と完全性が保証されます。学校の成績証明書は個々の学生に関する個人情報を記録するため、学生のプライバシーは最も重要です。成績証明書の配布の制御は、個々の学生によって厳密に保持されなければならず、各学生は、輸送中の自分の成績証明書の機密性を保護できなければなりません。
Communication of transcript content between originator, student, and ultimate recipient is most secure only if that communication is end-to-end. While the end-to-end argument [Sal84] is fundamental to the design of the Internet, it is also critical to the design of secure communication protocols (see Section 6.2 of RFC 1958 [RFC1958]). In contrast, securely communicating student information to a centralized (and otherwise uninvolved) third party clearly degrades student privacy and increases cost. Claims to the contrary are at best logically absurd and at worst darkly motivated.
発信者、学生、最終的な受信者の間の筆記録コンテンツの通信は、その通信がエンドツーエンドである場合にのみ、最も安全です。エンドツーエンドの議論[Sal84]はインターネットの設計の基本ですが、安全な通信プロトコルの設計にも重要です（RFC 1958 [RFC1958]のセクション6.2を参照）。対照的に、一元化された（または関与しない）第三者に学生情報を安全に通信すると、明らかに学生のプライバシーが低下し、コストが増加します。反対の主張は、せいぜい論理的にばかげており、最悪の場合はやる気がありません。
After students, transcript handling must address the interests of transcript recipients, which may include college admission officers, prospective employers, and scholarship foundations. Recipients must be able to evaluate the origin and integrity of received transcript documents easily and independently. Secondarily, recipients may benefit from mechanical extraction and summary of transcript content to support their own internal decision processes.
学生の後、成績証明書の処理は、大学の入学担当者、将来の雇用主、および奨学基金を含む、成績証明書の受領者の利益に対処する必要があります。受信者は、受信した筆記録文書の出所と完全性を簡単かつ独立して評価できる必要があります。第二に、受信者は、独自の内部決定プロセスをサポートするために、トランスクリプトコンテンツの機械的な抽出と要約の恩恵を受けることができます。
Finally, common transcript handling must address the needs of the transcript originator -- typically a secondary school guidance counselor or other school official. An originator's legitimate interests are reducing the cost of preparing transcript documents and meeting any legal or moral obligations to protect student privacy. Insofar as the very notion of electronic school transcripts implies their automated preparation by computers, dramatic cost reductions over traditional manual processes are also implicit. An originator's obligation to protect student privacy is most elegantly and inexpensively met by simply not conveying transcript information about a particular student to anyone other than that student.
最後に、一般的な筆記録の処理では、筆記録作成者（通常、中等学校の指導カウンセラーまたは他の学校関係者）のニーズに対応する必要があります。オリジネーターの正当な利益は、筆記録文書を準備するコストを削減し、学生のプライバシーを保護するための法的または道徳的な義務を果たすことです。電子学校の筆記録の概念そのものがコンピューターによる自動化された準備を意味する限り、従来の手動プロセスに比べて劇的なコスト削減も暗黙のうちにあります。学生のプライバシーを保護する創始者の義務は、特定の学生に関する筆記録情報をその学生以外の誰かに伝えないだけで、最もエレガントかつ安価に満たされます。
A protocol by which students must request transcript distributions addresses no actual student need but, rather, only the legal needs of third parties seeking to intervene in otherwise private communications. The additional effort of formal transcript requests is needed only when a mediating third party is involved, because, in many jurisdictions, sharing personal information with the third party legally requires student consent, and an electronic transcript request may be conveniently construed as implicit consent. Moreover, a formal transcript request-response protocol is not needed to document delivery of a transcript to its intended recipient. When the student, rather than a third party, directly conveys his/her transcript to a chosen recipient, that student has the greatest interest in successful communication, can observe any communication failures firsthand, and can take corrective action if needed. Familiar, standardized protocols provide unambiguous feedback to the student about successful transcript delivery. The SMTP protocol, in particular, is defined and implemented to be fail-safe, as described in Section 4.1.1.4 of its specification [RFC5321]:
受講者が筆記録配布を要求しなければならないプロトコルは、実際の受講者のニーズに対応するのではなく、個人的なコミュニケーションに介入しようとする第三者の法的ニーズのみに対応します。多くの管轄区域では、個人情報を第三者と合法的に共有するには学生の同意が必要であり、電子筆記録要求は暗黙の同意として都合よく解釈される可能性があるため、正式な筆記録要求の追加作業は必要です。さらに、目的の受信者へのトランスクリプトの配信を文書化するために、正式なトランスクリプト要求応答プロトコルは必要ありません。第三者ではなく学生が選択した受信者に筆記録を直接伝える場合、その学生はコミュニケーションの成功に最も関心があり、コミュニケーションの失敗を直接観察し、必要に応じて修正措置を講じることができます。慣れ親しんだ標準化されたプロトコルは、成績証明書の配信の成功について学生に明確なフィードバックを提供します。特に、SMTPプロトコルは、仕様[RFC5321]のセクション4.1.1.4で説明されているように、フェールセーフであるように定義および実装されています。
Receipt of the end of mail data indication requires the server to process the stored mail transaction information. This processing consumes the information in the reverse-path buffer, the forward-path buffer, and the mail data buffer, and on the completion of this command these buffers are cleared. If the processing is successful, the receiver MUST send an OK reply. If the processing fails, the receiver MUST send a failure reply. The SMTP model does not allow for partial failures at this point: either the message is accepted by the server for delivery and a positive response is returned or it is not accepted and a failure reply is returned. In sending a positive "250 OK" completion reply to the end of data indication, the receiver takes full responsibility for the message (see Section 6.1). Errors that are diagnosed subsequently MUST be reported in a mail message, as discussed in Section 4.4.
メールデータの終わりの表示を受け取るには、サーバーが保存されているメールトランザクション情報を処理する必要があります。この処理は、reverse-pathバッファー、forward-pathバッファー、およびメールデータバッファーの情報を消費し、このコマンドが完了すると、これらのバッファーはクリアされます。処理が成功した場合、受信者はOK応答を送信する必要があります。処理が失敗した場合、受信者は失敗の応答を送信する必要があります。この時点では、SMTPモデルは部分的な障害を許可していません。メッセージは配信のためにサーバーによって受け入れられ、肯定応答が返されるか、受け入れられずに失敗応答が返されます。データの終わりの表示に対する肯定的な「250 OK」完了応答の送信では、受信者がメッセージの全責任を負います（セクション6.1を参照）。セクション4.4で説明されているように、後で診断されるエラーはメールメッセージで報告する必要があります。
Existing, standardized technology simplifies the process of preparing and distributing secondary school transcripts. Using a computerized procedure, a secondary school administrator prepares a digital transcript document that records the academic achievements of a particular student and presents that document to that student. Using postal delivery, secure email, or other method, the student conveys digital copies of the prepared transcript to recipients of his or her choice. Using a computerized procedure, each recipient may independently verify that the received transcript has not been forged or altered in transit. Because the received transcript is digital, each recipient may use computerized procedures to extract and summarize transcript content for local review and processing.
既存の標準化されたテクノロジーにより、中等学校の成績証明書の作成と配布のプロセスが簡素化されます。中等学校の管理者は、コンピューター化された手順を使用して、特定の学生の学業成績を記録するデジタル筆記録文書を作成し、その文書をその学生に提示します。学生は郵便配達、安全な電子メール、またはその他の方法を使用して、準備した筆記録のデジタルコピーを自分の選択した受信者に伝えます。コンピュータ化された手順を使用して、各受信者は受信した筆記録が送信中に偽造または変更されていないことを個別に確認できます。受け取った筆記録はデジタルなので、各受信者はコンピュータ化された手順を使用して、ローカルのレビューと処理のために筆記録コンテンツを抽出して要約できます。
Preparing and delivering a secondary school transcript entails interaction among three kinds of participant -- transcript originator, student, and transcript recipient -- each of whom performs a distinct functional role. Interactions between each kind of participant are proscribed below.
中等学校の成績証明書を準備して提供するには、3種類の参加者（成績証明書の作成者、学生、成績証明書の受信者）の間でやり取りが行われます。各参加者間の相互作用は以下に禁止されています。
A transcript originator assembles and digitally signs academic transcripts that document the achievements of individual students in a secondary school. The role of transcript originator is frequently filled by the director of a high-school guidance department or other secondary school official. At fixed times throughout the school year, using then-current information from a student database, the guidance director executes a computer program that, for each relevant student, automatically creates an individual transcript report and digitally signs that report on the director's behalf. The format of each signed transcript document is defined in Section 5 below.
成績証明書の作成者は、中等学校の個々の生徒の成績を記録する成績証明書を組み立て、デジタル署名します。筆記録オリジネーターの役割は、高校の指導部または他の中等学校の職員によってしばしば満たされます。ガイダンスディレクターは、学生データベースの最新情報を使用して、学年中の一定の時間にコンピュータープログラムを実行します。コンピュータープログラムは、関連する学生ごとに、個別の筆記録レポートを作成し、ディレクターに代わってそのデジタル署名を行います。署名された筆記録文書の形式は、以下のセクション5で定義されています。
The principal responsibilities of a transcript originator are:
筆記録者の主な責任は次のとおりです。
1. Generate an OpenPGP key pair that can be used to sign school transcripts.
1. 学校の成績証明書の署名に使用できるOpenPGP鍵ペアを生成します。
2. Create and securely store a key revocation certificate for the signing key pair for possible future use should it be compromised.
2. 署名キーペアのキー失効証明書を作成して安全に保管し、侵害された場合に将来使用できるようにします。
3. Publish on the World Wide Web the public component of the transcript signing key pair, together with its OpenPGP fingerprint.
3. OpenPGPフィンガープリントと一緒にトランスクリプト署名鍵ペアの公開コンポーネントをワールドワイドウェブで公開します。
4. Securely store the private component of the signing key pair and protect its use with a judiciously chosen passphrase known only to the transcript originator.
4. 署名鍵ペアの秘密コンポーネントを安全に保存し、筆記録者のみが知っている慎重に選択されたパスフレーズでその使用を保護します。
5. Use the signing key pair to create and digitally sign transcripts for individual students.
5. 署名キーペアを使用して、個々の学生の筆記録を作成し、デジタル署名します。
6. Present each signed transcript confidentially to the individual student to which it pertains.
6. 署名された各筆記録を、関係する個々の生徒に秘密裏に提示します。
Once generated by the transcript originator, each transcript is conveyed to the relevant student using any means that protects the confidentiality of individual student data. For example, a digital transcript may be written to a CD-ROM storage disk and presented to the relevant student when he comes to school. Alternatively, that same CD-ROM could be sealed in an envelope and sent to the student via postal delivery. A student could present a USB flash drive in person at the school guidance office, and her digital transcript could be copied onto that drive. A digital school transcript could also be presented to the relevant student as a MIME attachment to an email message that is encrypted according to the OpenPGP specification. When email is used to convey school transcripts to students, formatting such messages as specified in Section 6 below will foster security and interoperability.
筆記録の作成者が生成すると、各筆記録は、個々の学生のデータの機密性を保護する手段を使用して、関連する学生に伝えられます。たとえば、デジタルトランスクリプトはCD-ROMストレージディスクに書き込まれ、関係する生徒が学校に来るときに提示されます。あるいは、同じCD-ROMを封筒に入れて郵送で生徒に送ることもできます。学生は学校の指導オフィスでUSBフラッシュドライブを直接提示し、彼女のデジタルトランスクリプトをそのドライブにコピーすることができます。 OpenPGP仕様に従って暗号化された電子メールメッセージへのMIME添付ファイルとして、デジタル学校の成績証明書を関連する生徒に提示することもできます。電子メールを使用して学校の成績証明書を生徒に伝える場合、以下のセクション6で指定されているようなメッセージをフォーマットすると、セキュリティと相互運用性が向上します。
After a student receives his/her transcript from its originator, that student is solely responsible for conveying that transcript to any recipients of his/her choosing, as described in Section 3.2 below.
生徒が作成者から筆記録を受け取った後、その生徒は、以下のセクション3.2で説明するように、自分の選択した受信者に筆記録を伝達する責任を単独で負います。
For several reasons, how students request generation of an academic transcript from their secondary school is a local matter that need not and ought not be addressed here.
いくつかの理由で、生徒が中等学校からの成績証明書の生成をどのように要求するかは、ローカルな問題であり、ここでは取り上げる必要はなく、また取り上げるべきではありません。
First, the volume of requests for transcripts is likely to be relatively low, because transcripts can be pre-issued to most students (e.g., graduating seniors) who are likely to need them. When transcripts are digital and easily duplicated by the student, there is no need to generate a new transcript document for each desired recipient. Accordingly, most transcript generation is driven not by student requests but rather by content updates arising from the predictable passing of marking periods or academic sessions throughout the school year. Thus, explicit requests for transcript generation will be the exception rather than the rule -- from students who have lost a previously issued transcript, or students leaving the school prior to their graduation.
まず、筆記録は、それを必要とする可能性が高いほとんどの学生（たとえば、卒業生）に事前に発行できるため、筆記録の要求の量は比較的少なくなります。筆記録がデジタルであり、学生が簡単に複製できる場合、目的の受信者ごとに新しい筆記録ドキュメントを生成する必要はありません。したがって、ほとんどの筆記録の生成は、学生の要求によってではなく、学期全体を通して予測可能な合格期間またはアカデミックセッションの経過から生じるコンテンツの更新によって駆動されます。したがって、以前に発行された筆記録を失った学生、または卒業前に学校を辞める学生からの、筆記録生成の明示的な要求は、規則ではなく例外になります。
Second, a historical motivation for formalizing transcript requests has been to satisfy the school's legal obligation to protect student privacy. In many legal jurisdictions, school officials are required to seek student authorization for releasing information to a third party. Elaborate procedures for requesting transcripts are attempts to codify or automate that authorization process. However, because, under the procedure defined here, each student's information is provided only to that student, no authorization for releasing information to a third party is required.
第二に、筆記録の要求を形式化する歴史的な動機は、生徒のプライバシーを保護するという学校の法的義務を満足させることでした。多くの法的管轄区域では、学校関係者は、第三者に情報を公開するための学生の承認を求める必要があります。トランスクリプトを要求するための入念な手順は、その承認プロセスを体系化または自動化する試みです。ただし、ここで定義された手順では、各学生の情報はその学生にのみ提供されるため、情報を第三者に公開するための承認は必要ありません。
Third, a codified transcript request protocol affords almost no benefit beyond enabling third-party processors to assume the role of transcript originator and/or distributor. Students need no formal "acknowledgment" of their transcript requests: the transcript itself serves that purpose. Because a digital transcript is easily generated by an automated procedure, there is no benefit to returning a request acknowledgment rather than the document actually requested. The primary goal of this protocol design is to strengthen student privacy and agency by eliminating third-party intrusion into what would otherwise be private, bilateral interactions between a student and his school. To codify transcript requests is to undercut directly that fundamental purpose, while gratuitously restricting local interactions between student and school.
第3に、成文化された筆記録要求プロトコルは、サードパーティのプロセッサが筆記録の作成者または配布者、あるいはその両方の役割を果たすことを可能にすることを除いて、ほとんどメリットがありません。受講者は筆記録リクエストの正式な「承認」を必要としません。筆記録自体がその目的を果たします。デジタルトランスクリプトは自動化された手順で簡単に生成されるため、実際に要求されたドキュメントではなく、要求の確認応答を返すメリットはありません。このプロトコル設計の主な目的は、学生と彼の学校との間の私的な双方向のやりとりへの第三者の侵入を排除することにより、学生のプライバシーとエージェンシーを強化することです。筆記録の要求を成文化することは、学生と学校の間のローカルなやり取りを不当に制限しながら、その基本的な目的を直接損なうことです。
When each student -- rather than a school official or mediating third party -- exercises principal control of distributing his or her own transcript information, any need for transcript requests is largely obviated. Thus, exchanging and processing such requests is properly a local matter and not further addressed here.
各生徒が、学校の職員や仲介の第三者ではなく、自分の筆記録情報を配布するという主要な制御を行う場合、筆記録要求の必要性はほとんどなくなります。したがって、そのような要求の交換と処理は適切にローカルな問題であり、ここではこれ以上取り上げません。
When a student is asked (e.g., by a college admissions office or prospective employer) to provide an official transcript of his or her academic achievements, that student may send to the requesting party a copy of the digitally signed transcript document that he has previously received from his secondary school. In this context, the party requesting that the student send a transcript is called a transcript recipient. Because it is the student who conveys his own transcript information, he or she unambiguously controls the set of recipients, and neither the secondary school nor any third party is responsible for or privy to the identities of his correspondents. Similarly, the student is responsible for assuring the privacy of his or her personal information as he conveys it to these recipients.
学生が自分の学業成績の公式筆記録を提出するように（例えば、大学の入学事務局または将来の雇用主から）要求された場合、その学生は、以前に受け取ったデジタル署名された筆記録文書のコピーを要求当事者に送信できます。彼の中等学校から。この文脈では、学生に筆記録の送信を要求する当事者を筆記録受信者と呼びます。自身の筆記録情報を伝えるのは学生なので、彼または彼女は明確に受信者のセットを制御し、中等学校も第三者も彼の特派員の身元について責任も秘密もしません。同様に、学生は自分の個人情報をこれらの受信者に伝える際に、その個人情報のプライバシーを保証する責任があります。
The student may convey his transcript to his chosen recipient using any mutually agreeable strategy. For example, he may print a copy of his transcript onto a postcard and send it via postal delivery. This strategy does not strongly protect the confidentiality of the student's information in transit, nor does this strategy allow the recipient to automate verification or other processing of the received transcript information. Sending a paper transcript sealed in a postal envelope better protects student confidentiality, but similarly restricts the recipient's ability to verify or process transcript contents. By copying his digital transcript onto a CD-ROM storage disk and sending that disk, sealed in a postal envelope, via surface mail, the recipient can automatically verify and process the transcript content, although protection of student confidentiality in transit might be stronger.
学生は、相互に同意できる戦略を使用して、選択した受信者に筆記録を伝えることができます。たとえば、彼は筆記録のコピーをはがきに印刷し、郵送することができます。この戦略は、送信中の学生の情報の機密性を強力に保護するものではなく、受信者が受信した筆記録情報の検証やその他の処理を自動化することもできません。郵便封筒に封印された筆記録を送信すると、学生の機密性が保護されますが、同様に、受講者が筆記録の内容を確認または処理する機能が制限されます。デジタルトランスクリプトをCD-ROMストレージディスクにコピーし、そのディスクを郵送で封印して郵送することにより、受信者はトランスクリプトコンテンツを自動的に確認および処理できますが、輸送中の学生の機密性の保護はより強力です。
Alternatively, a student could send a copy of the digital transcript provided by his secondary school merely by attaching the relevant computer file to an email message addressed to the recipient. If the student completely trusts the end-to-end email transmission path from himself to his intended recipient (e.g., if student and recipient are connected by a common, private network), then the student could send his transcript in a plaintext email; otherwise, the student SHOULD encrypt the email contents to protect his privacy during transmission.
または、生徒は、関連するコンピュータファイルを受信者宛の電子メールメッセージに添付するだけで、中等学校が提供するデジタルトランスクリプトのコピーを送信することもできます。学生が自分から目的の受信者へのエンドツーエンドの電子メール送信パスを完全に信頼している場合（たとえば、学生と受信者が共通のプライベートネットワークで接続されている場合）、学生は筆記録をプレーンテキストの電子メールで送信できます。それ以外の場合、学生は送信中のプライバシーを保護するために電子メールの内容を暗号化する必要があります。
If a student chooses to convey his/her school transcript to a transcript recipient via electronic mail, then the principal responsibilities of that student are:
生徒が自分の学校の成績証明書を電子メールで成績証明書の受信者に伝えることを選択した場合、その生徒の主な責任は次のとおりです。
1. Create a personal email account and associated email address from which transmissions of the student's signed school transcript may be sent.
1. 個人の電子メールアカウントと関連する電子メールアドレスを作成し、そこから学生の署名された学校の成績証明書の送信を送信します。
2. For each potential recipient of the student's signed school transcript, discover and record the email address and the public OpenPGP key published by that transcript recipient.
2. 学生の署名された学校の筆記録の潜在的な受信者ごとに、その筆記録の受信者によって公開された電子メールアドレスと公開OpenPGPキーを見つけて記録します。
3. Import the OpenPGP public key for each chosen recipient into the local OpenPGP key database.
3. 選択した各受信者のOpenPGP公開鍵をローカルのOpenPGP鍵データベースにインポートします。
4. Use an email client application that implements the OpenPGP/MIME specification [RFC3156] in order to encrypt and transmit a copy of the signed school transcript to each chosen recipient.
4. OpenPGP / MIME仕様[RFC3156]を実装する電子メールクライアントアプリケーションを使用して、署名された学校の成績証明書のコピーを暗号化し、選択した各受信者に送信します。
Using common formats and methods to convey transcript content protects students while also simplifying processing for transcript recipients. The representation of transcripts as specified in Section 5 and the use of the transmission formats specified in
トランスクリプトコンテンツを伝達するために一般的な形式と方法を使用すると、受講者を保護すると同時に、トランスクリプト受信者の処理を簡素化できます。セクション5で指定されているトランスクリプトの表現と、で指定されている伝送フォーマットの使用
Section 6 afford privacy and autonomy to students. By using these formats, recipients may independently verify the origin and integrity of the transcript information that students provide. Common transcript representation also allows recipients to automate the storage, analysis, and review of received transcripts.
セクション6では、プライバシーと自律性を学生に提供します。これらのフォーマットを使用することにより、受信者は、学生が提供する筆記録情報の出所と完全性を独自に検証できます。共通の筆記録表現により、受信者は受信した筆記録の保存、分析、レビューを自動化することもできます。
However, a student cannot use the format specified here to convey his/her transcript to a chosen recipient unless that recipient is prepared to participate in the exchange. The principal responsibilities of a transcript recipient are:
ただし、受講者が交換に参加する準備ができていない限り、学生はここで指定された形式を使用して、選択した受講者に筆記録を伝えることはできません。文字起こしの受信者の主な責任は次のとおりです。
1. Generate an OpenPGP key pair that can be used to encrypt student transmissions of signed school transcripts to the recipient.
1. 受信者への署名された学校の成績証明書の生徒の送信を暗号化するために使用できるOpenPGP鍵ペアを生成します。
2. Create and securely store a key revocation certificate for the key pair generated above for possible future use in the event that the private key component is compromised.
2. 上記で生成された鍵ペアの鍵失効証明書を作成して安全に保管し、秘密鍵コンポーネントが危険にさらされた場合に将来使用できるようにします。
3. Create a (preferably dedicated) email address and mailbox to which students may direct transmissions of signed school transcripts.
3. 生徒が署名済みの成績証明書の送信を指示できる（専用の）電子メールアドレスとメールボックスを作成します。
4. Publish on the World Wide Web both the dedicated transcript email address and the public component of the OpenPGP key pair generated above, together with its OpenPGP fingerprint.
4. 上記のように生成されたOpenPGPキーペアの専用のトランスクリプト電子メールアドレスと公開コンポーネントの両方を、OpenPGPフィンガープリントと一緒にWorld Wide Webで公開します。
5. Securely store the private component of the OpenPGP key pair generated above and guard its use with a judiciously chosen passphrase known only to the transcript recipient.
5. 上記で生成されたOpenPGPキーペアのプライベートコンポーネントを安全に保存し、トランスクリプトの受信者だけが知っている慎重に選択されたパスフレーズでその使用を保護します。
6. Assemble a collection of public OpenPGP keys published by legitimate transcript originators.
6. 正当な筆記録作成者によって公開された公開OpenPGP鍵のコレクションを集めます。
7. Receive and decrypt transcripts transmitted by students.
7. 学生が送信した筆記録を受信して復号化します。
8. Validate the origin and integrity of each received transcript using the public OpenPGP key of the relevant transcript originator.
8. 関連する筆記録作成者の公開OpenPGPキーを使用して、受信した各筆記録の作成元と整合性を検証します。
The similarity between the EESST transcript format and generic OpenPGP/MIME email messages allows transcript recipients to inspect, verify, and extract received school transcripts using existing, widely deployed email clients. By using email client applications that support both the MIME and OpenPGP specifications, transcript recipients should easily be able to verify the signature of the transcript originator and to save the various transcript components locally for later review or processing.
EESSTトランスクリプト形式と一般的なOpenPGP / MIME電子メールメッセージの類似性により、トランスクリプト受信者は、既存の広く展開されている電子メールクライアントを使用して、受信した学校のトランスクリプトを検査、検証、および抽出できます。筆記録の受信者は、MIME仕様とOpenPGP仕様の両方をサポートする電子メールクライアントアプリケーションを使用することにより、筆記録作成者の署名を簡単に確認し、さまざまな筆記録コンポーネントを後で確認または処理できるようにローカルに保存できます。
Using familiar email client applications for receiving and reviewing small numbers of received school transcripts does not preclude using more automated systems to meet the needs of university admissions departments or large employers. Larger-volume transcript recipients might ask students to direct their school transcripts to a particular email mailbox. Transcripts so delivered could be periodically received, validated, and otherwise organized by specialized application software. Information in the computational component of received transcripts might be incorporated into a candidate database to simplify more quantitative evaluations of the applicant pool.
受信した少数の成績証明書を受信して確認するために使い慣れた電子メールクライアントアプリケーションを使用しても、大学入試部門や大規模な雇用主のニーズを満たすために自動化されたシステムを使用することを妨げません。大量の筆記録の受信者は、生徒に学校の筆記録を特定のメールボックスに送信するように依頼する場合があります。このように配信された筆記録は、定期的に受信、検証、またはその他の方法で、専用のアプリケーションソフトウェアによって整理できます。受信したトランスクリプトの計算コンポーネントの情報を候補データベースに組み込んで、申請者プールのより定量的な評価を簡素化できます。
The content of a school transcript is represented as a single MIME body part whose content type is "multipart/mixed". This multipart representation comprises individual MIME elements that represent (in order) prefatory comments from the transcript originator regarding the validation and interpretation of the represented transcript (described in Section 4.1), a rendering of the relevant school transcript suitable for automated processing (described in Section 4.2), and a rendering of that same school transcript suitable for human review and consideration (described in Section 4.3). Figure 3 below schematically presents the MIME structure used to represent transcript content; Figure 4 illustrates an example representation of transcript content.
学校の筆記録のコンテンツは、コンテンツタイプが「multipart / mixed」である単一のMIMEボディパーツとして表されます。このマルチパート表現は、表現された筆記録の検証と解釈（セクション4.1で説明）、自動処理に適した関連する学校の筆記録のレンダリング（セクションで説明）に関する筆記録オリジネーターからの（コメント順の）予備コメントを表す個々のMIME要素で構成されます。 4.2）、および人間による確認と検討に適した同じ学校の筆記録のレンダリング（セクション4.3で説明）。以下の図3は、トランスクリプトコンテンツを表すために使用されるMIME構造を概略的に示しています。図4は、トランスクリプトコンテンツの表現例を示しています。
Every representation of transcript content MUST include exactly the following set of MIME content headers:
トランスクリプトコンテンツのすべての表現には、次のMIMEコンテンツヘッダーのセットを正確に含める必要があります。
Content-Type: This header is defined in Section 5 of the MIME format specification [RFC2045] and, when associated with the content of a signed school transcript, MUST have the value "multipart/ mixed".
Content-Type：このヘッダーは、MIME形式仕様[RFC2045]のセクション5で定義されており、署名された学校の成績証明書のコンテンツに関連付けられている場合、値は「multipart / mixed」でなければなりません。
Content-Description: This header is defined in Section 8 of the MIME format specification [RFC2045]. Its value provides humans with "descriptive information" about the content of the represented school transcript. Notwithstanding the statement in RFC 2045 that a content description header is optional, this header MUST be included in the MIME representation of school transcript content.
Content-Description：このヘッダーは、MIME形式仕様[RFC2045]のセクション8で定義されています。その価値は、表現された学校の成績証明書の内容に関する「説明的な情報」を人間に提供します。コンテンツ記述ヘッダーはオプションであるというRFC 2045のステートメントにかかわらず、このヘッダーは学校の筆記録コンテンツのMIME表現に含める必要があります。
MIME-Version: This header is defined in Section 4 of the MIME format specification [RFC2045]. Its value identifies the version of the MIME specification to which the associated body part conforms. Currently, the value of this header MUST always be "1.0". Sometimes, the EESST specification can require an appearance of the MIME-Version header where it is not otherwise strictly required by the MIME format specification. These seemingly gratuitous MIME-Version headers are deliberately introduced to help users who may need to apply less-capable email clients recursively in order to navigate and display a transmitted transcript.
MIME-Version：このヘッダーは、MIME形式仕様[RFC2045]のセクション4で定義されています。その値は、関連するボディパーツが準拠するMIME仕様のバージョンを識別します。現在、このヘッダーの値は常に「1.0」である必要があります。 EESST仕様では、MIME形式の仕様で厳密に要求されていないMIME-Versionヘッダーの外観が必要になる場合があります。これらの見かけ上不必要なMIME-Versionヘッダーは、送信されたトランスクリプトをナビゲートして表示するために、能力の低い電子メールクライアントを再帰的に適用する必要があるユーザーを支援するために意図的に導入されています。
Eesst-Version: The value of this header identifies the version of the EESST format to which the represented school transcript conforms. Currently, the value of this header MUST always be "1.0".
Eesst-Version：このヘッダーの値は、表された学校の筆記録が準拠するEESST形式のバージョンを識別します。現在、このヘッダーの値は常に「1.0」である必要があります。
From: The value of this header identifies the originator of the represented school transcript. This value names the originating official, his organizational title, and includes, enclosed within angle brackets, the identity of the OpenPGP key with which the represented school transcript has been digitally signed.
From：このヘッダーの値は、表現された学校の筆記録の作成者を識別します。この値は、元の役人とその組織の肩書を示し、山かっこで囲まれた、表された学校の筆記録がデジタル署名されたOpenPGPキーのIDを含みます。
Organization: The value of this header identifies the organization or institution to which the originator of the relevant message belongs. Within a school transcript document, the value of this header identifies the secondary school that has issued the represented school transcript. By convention, the value of this header names the originating institution along with its geographical location.
組織：このヘッダーの値は、関連するメッセージの発信者が所属する組織または機関を識別します。学校の成績証明書ドキュメント内で、このヘッダーの値は、表現された学校の成績証明書を発行した中等学校を識別します。慣例により、このヘッダーの値は、地理的な場所とともに発信機関を示します。
Subject: The value of this header provides humans with "descriptive information" about the semantic content of the represented school transcript. Inclusion of this header is optional, but, if included, its value MUST match that of the "Content-Description" header above. The presence of the "Subject" header helps some email reader applications to present school transcript transmissions more elegantly.
件名：このヘッダーの値は、表現された学校の筆記録の意味内容に関する「説明情報」を人間に提供します。このヘッダーを含めることはオプションですが、含める場合、その値は上記の「Content-Description」ヘッダーの値と一致する必要があります。 「件名」ヘッダーの存在は、一部の電子メールリーダーアプリケーションが学校の筆記録の送信をよりエレガントに表示するのに役立ちます。
Date: The value of this header identifies the date on which the represented school transcript was created, and its format MUST be consistent with Section 3.3 of the specification for email messages [RFC5322].
日付：このヘッダーの値は、表現された学校の筆記録が作成された日付を識別し、その形式は電子メールメッセージの仕様[RFC5322]のセクション3.3と一致している必要があります。
With the exception of the optional "Subject" header, each header enumerated above must appear in the MIME body part that represents the aggregate content of a school transcript. No other headers are permitted, and the allowed set of headers may appear in any order. Example MIME headers for transcript content are presented in Figure 4. In the figure, "PESC" stands for the Postsecondary Electronic Standards Council; see Section 4.2 for more information.
オプションの "Subject"ヘッダーを除いて、上記で列挙された各ヘッダーは、学校の成績証明書の集計コンテンツを表すMIME本文部分に表示される必要があります。他のヘッダーは許可されておらず、許可されたヘッダーのセットは任意の順序で表示できます。文字起こしコンテンツのMIMEヘッダーの例を図4に示します。図では、「PESC」はPostsecondary Electronic Standards Councilの略です。詳細については、セクション4.2を参照してください。
+--------------------------------------------------+
| TRANSCRIPT CONTENT |
| Content-Type: multipart/mixed |
| |
| +-------------------------------------------+ |
| | TRANSCRIPT PREFACE | |
| | Content-Type: text/plain | |
| | | |
| | Body represents transcript preface | |
| +-------------------------------------------+ |
| |
| +-------------------------------------------+ |
| | COMPUTATIONAL TRANSCRIPT | |
| | Content-Type: application/xml | |
| | | |
| | Body represents PESC XML computational | |
| | transcript | |
| +-------------------------------------------+ |
| |
| +-------------------------------------------+ |
| | DISPLAY TRANSCRIPT | |
| | Content-Type: application/pdf | |
| | | |
| | Body represents PDF display transcript | |
| +-------------------------------------------+ |
+--------------------------------------------------+
Figure 3: MIME Structure of Transcript Content
図3：トランスクリプトコンテンツのMIME構造
Content-Type: multipart/mixed; boundary="===============BBBBBBBBBB=="
MIME-Version: 1.0
Content-Description: Official School Transcript for Hermione Granger
Subject: Official School Transcript for Hermione Granger
From: Transcript Authority at Hogwarts School
<transcript-authority@hogwarts.edu.example>
Organization: Hogwarts School for Witchcraft and Wizardry
Eesst-Version: 1.0
Date: Fri, 22 Mar 2013 09:55:06 -0600
--===============BBBBBBBBBB==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="preface.txt"
Content-Description: School Transcript Preface
To Whom It May Concern:
ご担当者様：
This academic transcript describes the accomplishments of an ...
この学術筆記録は、...
--===============BBBBBBBBBB==
Content-Type: application/xml
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="transcript.xml"
Content-Description: School Transcript rendered as PESC XML
<HSTrn:HighSchoolTranscript=20xmlns:AcRec=3D"urn:org:pesc:sector:Acad
...
cord></Student></HSTrn:HighSchoolTranscript>
--===============BBBBBBBBBB==
Content-Type: application/pdf
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="transcript.pdf"
Content-Description: School Transcript rendered as PDF
JVBERi0xLjMNCiWTjIueIFJlcG9ydExhYiBHZW5lcmF0ZWQgUERGIGRvY3VtZW50IGh0d
...
IC9Sb290IDEwIDAgUg0KIC9TaXplIDE2ID4+DQpzdGFydHhyZWYNCjE3OTIzDQolJUVPR
--===============BBBBBBBBBB==
Figure 4: Example Transcript Content
図4：トランスクリプトコンテンツの例
A school transcript preface conveys generic comments about a school transcript from the originating school official. This commentary is in a form that is widely readable by humans without special application tools. This commentary SHOULD be generic in character, providing general information about the preparation and interpretation of transcripts issued by the originating institution; the transcript preface SHOULD NOT provide information about an individual student. The rhetorical form of a transcript preface is sometimes that of a cover letter addressed to a generic transcript recipient. For example, a preface could provide instructions on how to verify the digital signature on the transcript or an explanation of unusual grading practices at the issuing school. A school transcript preface is represented as a MIME body part whose content type is "text/plain".
学校の筆記録の序文は、元の学校関係者からの学校の筆記録に関する一般的なコメントを伝えます。この解説は、特別なアプリケーションツールがなくても、人間が広く読める形式になっています。この解説は一般的な性質のものである必要があり、元の機関が発行した筆記録の準備と解釈に関する一般的な情報を提供する必要があります。筆記録の序文は、個々の学生に関する情報を提供してはなりません。文字起こしの序文の修辞的な形式は、一般的な文字起こしの宛先に宛てられたカバーレターのそれである場合があります。たとえば、序文では、筆記録のデジタル署名を検証する方法や、発行校での通常とは異なる成績評価の説明を提供できます。学校の筆記録の序文は、コンテンツタイプが「text / plain」であるMIME本文部分として表されます。
When a school transcript is encapsulated for transmission into a larger email message, arbitrary text within a transcript preface could be accidentally misinterpreted as structural MIME boundaries or email headers. The likelihood of such errors is reduced when preface content does not include lines that begin with hyphen (-) characters, angle bracket (>) characters, or the word "From." Although, ideally, the transcript preface should be readable by humans without special assistance, when these constructs absolutely cannot be avoided within preface text, transcript originators SHOULD apply a content transfer encoding to the preface that insulates it from misinterpretation by intermediary mail transfer agents.
学校の筆記録がカプセル化されてより大きな電子メールメッセージに送信されると、筆記録の序文内の任意のテキストが誤って構造的MIME境界または電子メールヘッダーとして解釈される可能性があります。序文のコンテンツにハイフン（-）文字、山かっこ（>）文字、または単語 "From"で始まる行が含まれていない場合、このようなエラーの可能性は低くなります。理想的には、筆記録の序文は特別な支援なしに人間が読めるようにする必要がありますが、これらの構成が序文テキスト内で絶対に避けられない場合、筆記者は、仲介メール転送エージェントによる誤解から隔離するコンテンツ転送エンコーディングを序文に適用する必要があります。
The representation of a transcript preface SHOULD NOT include any header fields beyond those enumerated in the specification for the format of MIME message bodies [RFC2045].
文字起こしの序文の表現には、MIMEメッセージ本文の形式[RFC2045]の仕様で列挙されているもの以外のヘッダーフィールドを含めるべきではありません（SHOULD NOT）。
A computational school transcript represents the academic accomplishments of an individual student in a form suitable for automated processing. Accordingly, the content of a computational school transcript is rendered in Extensible Markup Language (XML) [XML11] and conveyed as a MIME body part whose content type is "application/xml". The syntax of the data conveyed by a computational transcript MUST conform to the XML schema for High School Transcripts, Version 1.3.0 [Fun12b], published by the Postsecondary Electronic Standards Council (PESC). This XML schema depends in turn upon the Academic Record XML schema, Version 1.7.0 [Fun12a] and the Core Main XML schema, Version 1.2.0 [Mar06], also
コンピュータ学校の成績証明書は、自動処理に適した形式で個々の学生の学業成績を表しています。したがって、学校の成績証明書の内容はExtensible Markup Language（XML）[XML11]でレンダリングされ、コンテンツタイプが "application / xml"のMIMEボディパーツとして伝達されます。計算の筆記録によって伝えられるデータの構文は、Postsecondary Electronic Standards Council（PESC）によって発行された高校の筆記録、バージョン1.3.0 [Fun12b]のXMLスキーマに準拠する必要があります。このXMLスキーマは、Academic Record XMLスキーマ、バージョン1.7.0 [Fun12a]、およびコアメインXMLスキーマ、バージョン1.2.0 [Mar06]にも依存しています。
published by PESC. Detailed semantics for the data elements defined by these XML schema are defined in the PESC XML implementation guide, Version 1.3.0 [Ste12], which also provides usage examples.
PESCによって発行されました。これらのXMLスキーマによって定義されたデータ要素の詳細なセマンティクスは、PESC XML実装ガイド、バージョン1.3.0 [Ste12]で定義されており、使用例も提供されています。
In order to protect student privacy, this specification does not require a school transcript to convey any particular student information but, rather, defines only a common format for whatever student information may be voluntarily exchanged between consenting parties. The scope of the information exchanged is a completely local matter, and a transcript originator MAY omit from transcript content any information (e.g., a student's social security number, the identity and location of a student's parents, a student's race, ethnicity, or transgender status) that might be regarded locally as sensitive or irrelevant. Indeed, the requirement that a computational transcript conform syntactically to the PESC XML schema imposes few, if any, constraints upon the transcript originator's choices regarding transcript content. Figure 5 illustrates a minimal set of XML elements that satisfies the syntactic requirements of the PESC XML schema. A computational transcript need convey no more information about an individual student than what little is conveyed by that figure.
学生のプライバシーを保護するために、この仕様では学校の成績証明書に特定の学生情報を伝える必要はありませんが、同意する当事者間で自主的に交換される学生情報の共通形式のみを定義しています。交換される情報の範囲は完全にローカルな事項であり、筆記録者は筆記録コンテンツから情報（たとえば、学生の社会保障番号、学生の両親の身元と場所、学生の人種、民族、またはトランスジェンダーのステータス）を省略できます。 ）局所的に敏感または無関係と見なされる可能性があります。実際、計算による筆記録が構文的にPESC XMLスキーマに準拠するという要件は、筆記録コンテンツに関する筆記録作成者の選択に制約があったとしても、ほとんど制約を課しません。図5は、PESC XMLスキーマの構文要件を満たすXML要素の最小セットを示しています。計算上の筆記録は、個々の生徒について、その数字によってほとんど伝えられていない情報以上の情報を伝える必要はありません。
In order to prevent implicit monitoring and control of student interactions with transcript recipients, this specification restricts certain uses of the PESC XML schema by transcript originators. In every computational transcript, the "Destination" sub-element of the "DataTransmission" element MUST convey no distinguishable information and have the particular representation
受講者とトランスクリプト受信者との対話を暗黙的に監視および制御することを防ぐため、この仕様では、トランスクリプトの作成者によるPESC XMLスキーマの特定の使用を制限しています。すべての計算の筆記録で、「DataTransmission」要素の「Destination」サブ要素は区別可能な情報を伝達せず、特定の表現を持っている必要があります
"<Destination><Organization/></Destination>"
that is illustrated in Figure 5. This requirement assures that a student may use self-made copies of a signed transcript document for whatever purposes he/she chooses without further consultation with issuing school officials. If the transcript originator is allowed to brand particular destinations onto each copy of a student transcript, then the originator can easily monitor and (to some degree) control the set of college admissions officers, prospective employers, or other third parties to whom the student is providing that transcript. Transcript recipients MUST reject any transcript whose content in any way specifies or restricts the audience, recipient, or distribution for that transcript. Notwithstanding this restriction upon the "Destination" element, the "Source" element SHOULD be included within a computational transcript and convey information sufficient to identify the secondary school or other institution by which the relevant transcript is issued.
これは、図5に示されています。この要件により、学生は、発行する学校関係者とのさらなる協議なしに、選択した目的にかかわらず、署名済み筆記録ドキュメントの自作コピーを使用できることが保証されます。筆記録者が特定の目的地を学生の筆記録の各コピーにブランド化することを許可されている場合、創始者は、学生がいる大学入学責任者、将来の雇用主、またはその他の第三者のセットを簡単に監視および（ある程度）制御できます。その筆記録を提供します。トランスクリプトの受信者は、そのトランスクリプトの対象者、受信者、または配布を何らかの方法で指定または制限するトランスクリプトを拒否する必要があります。 「Destination」要素に対するこの制限にもかかわらず、「Source」要素は計算の筆記録に含まれ、関連する筆記録が発行される中等学校または他の機関を識別するのに十分な情報を伝える必要があります。
<HSTrn:HighSchoolTranscript
xmlns:HSTrn="urn:org:pesc:message:HighSchoolTranscript:v1.3.0"
xmlns:AcRec="urn:org:pesc:sector:AcademicRecord:v1.7.0"
xmlns:core="urn:org:pesc:core:CoreMain:v1.12.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:org:pesc:message:HighSchoolTranscript:v1.3.0
HighSchoolTranscript_v1.3.0.xsd">
<TransmissionData>
<DocumentID>X</DocumentID>
<CreatedDateTime>2011-04-04T09:30:47-05:00</CreatedDateTime>
<DocumentTypeCode>StudentRequest</DocumentTypeCode>
<TransmissionType>MutuallyDefined</TransmissionType>
<Source>
<Organization/>
</Source>
<Destination>
<Organization/>
</Destination>
</TransmissionData>
<Student>
<Person>
<Name/>
</Person>
<AcademicRecord/>
</Student>
</HSTrn:HighSchoolTranscript>
Figure 5: A Minimal Set of PESC XML Elements
図5：PESC XML要素の最小セット
Additional restrictions on the use of the PESC XML schema foster common, unambiguous interpretation and simplified processing of computational transcripts:
PESC XMLスキーマの使用に関する追加の制限は、一般的な、明確な解釈と、計算トランスクリプトの簡素化された処理を促進します。
1. In order to satisfy the minimal syntactic requirements of the PESC XML schema, every computational transcript MUST comprise at least those XML elements that appear in Figure 5. Even when a transcript originator seeks to convey no information within a computational transcript, the computational transcript must be included within the relevant transcript content, and its payload must have the form illustrated in Figure 5.
1. PESC XMLスキーマの最小限の構文要件を満たすために、すべての計算トランスクリプトは、少なくとも図5に表示されるXML要素で構成する必要があります。トランスクリプトオリジネーターが計算トランスクリプト内で情報を伝えようとしない場合でも、計算トランスクリプトは関連するトランスクリプトコンテンツに含まれ、そのペイロードは図5に示す形式でなければなりません。
2. Consistent with the PESC XML schema, any value ascribed to the "DocumentID" XML element must be at least one non-whitespace character in length.
2. PESC XMLスキーマと一致して、「DocumentID」XML要素に割り当てられた値は、少なくとも1つの非空白文字の長さでなければなりません。
3. Consistent with the PESC XML schema, any value ascribed to the "CreatedDateTime" XML element must have the form of an XML "dateTime" value, as defined in Section 3.2.7 of the XML Schema Datatype specification [XSD].
3. PESC XMLスキーマと一致して、 "CreatedDateTime" XML要素に起因するすべての値は、XMLスキーマデータタイプ仕様[XSD]のセクション3.2.7で定義されているように、XML "dateTime"値の形式である必要があります。
4. Lest the origin and correct handling for a computational transcript be misunderstood, the value ascribed to the "DocumentTypeCode" XML element MUST be "StudentRequest".
4. 「DocumentTypeCode」XML要素に割り当てられた値は「StudentRequest」である必要があるため、計算トランスクリプトの起源と正しい処理を誤解しないようにしてください。
5. Lest the origin and correct handling for a computational transcript be misunderstood, the value ascribed to the "TransmissionType" XML element MUST be "MutuallyDefined".
5. 計算トランスクリプトの起源と正しい処理が誤解されないように、 "TransmissionType" XML要素に起因する値は "MutuallyDefined"である必要があります。
6. With the exception of those XML elements that appear in Figure 5, information that is not provided in a computational transcript MUST be represented by entirely omitting the relevant XML data element; omitted information MUST NOT be represented by including an XML element whose textual value is of zero length or contains only whitespace.
6. 図5に表示されているXML要素を除いて、計算の筆記録で提供されない情報は、関連するXMLデータ要素を完全に省略して表す必要があります。省略された情報は、テキスト値の長さがゼロであるか、空白のみを含むXML要素を含めることによって表現してはなりません（MUST NOT）。
The representation of a computational transcript SHOULD NOT include any header fields beyond those enumerated in the specification for the format of MIME message bodies [RFC2045]. Although any valid content transfer encoding is acceptable for a computational school transcript, the "quoted-printable" encoding is preferred.
計算トランスクリプトの表現には、MIMEメッセージ本文の形式[RFC2045]の仕様で列挙されているもの以外のヘッダーフィールドを含めるべきではありません（SHOULD NOT）。有効なコンテンツ転送エンコーディングはすべて、学校の成績証明書に使用できますが、「quoted-printable」エンコーディングが推奨されます。
A display school transcript describes the academic accomplishments of an individual student in a form suitable for human reading and review. A display school transcript is represented as a MIME body part whose content type is "application/pdf" and whose content conforms to the Portable Document Format (PDF) specification [PDF17]. A display school transcript may comprise one or more physical pages.
ディスプレイスクールの成績証明書は、個々の生徒の学業成績を、人間の読書と復習に適した形式で説明します。学校の成績証明書は、コンテンツタイプが「application / pdf」であり、そのコンテンツがPortable Document Format（PDF）仕様[PDF17]に準拠しているMIME本文部分として表されます。学校の成績証明書は、1つ以上の物理ページで構成されます。
In order to reduce the chance that the recipient of a signed school transcript could misinterpret its content, the computational component (described in Section 4.2 above) and the display component (defined here) of each signed school transcript SHOULD convey, to the greatest degree possible, identical information about the academic accomplishments of the relevant student.
署名された学校の成績証明書の受信者がその内容を誤って解釈する可能性を減らすために、各署名された学校の成績証明書の計算コンポーネント（上記のセクション4.2で説明）と表示コンポーネント（ここで定義）は、可能な限り伝達する必要があります（SHOULD） 、関連する学生の学業成績に関する同一の情報。
Nothing in this specification should be construed as requiring
implementation or use of digital signature features embedded in
individual PDF documents pursuant to the PDF specification. Rather,
the data integrity and origin identity of all components in a school
transcript --- including the PDF display transcript --- are
adequately protected by the OpenPGP signature of the transcript
originator, required by this specification. Accordingly,
implementation of PDF-specific signature features is optional and
largely unwarranted; although transcript recipients MUST accept
transcripts that include PDF signatures, recipients SHOULD neither
verify nor depend upon the embedded signatures themselves.
Transcript originators MUST NOT use the encryption features described in the PDF specification to encrypt a display school transcript. The OpenPGP encryption mechanisms specified in Section 6 below adequately protect the confidentiality of student information while in transit. Thus, separately encrypting the display transcript is redundant. Double encryption increases implementation complexity while also increasing security risk by requiring additional key distributions. Transcript recipients MUST NOT accept or process school transcripts for which the PDF display component is independently encrypted.
成績証明書の作成者は、PDF仕様に記載されている暗号化機能を使用して、ディスプレイスクールの成績証明書を暗号化してはなりません。以下のセクション6で指定されているOpenPGP暗号化メカニズムは、移動中の学生情報の機密性を適切に保護します。したがって、表示トランスクリプトを個別に暗号化することは冗長です。二重暗号化は実装の複雑さを増大させると同時に、追加のキー配布を必要とすることによりセキュリティリスクを増大させます。成績証明書の受信者は、PDF表示コンポーネントが個別に暗号化されている学校の成績証明書を受け入れたり処理したりしてはなりません。
Previous work [RFC3778] identifies security considerations arising from using the PDF as a MIME media type. Among these considerations is that PDF documents may include executable "scripts" or references to external, executable plug-in modules. Including arbitrary executable programs (or references thereto) in a PDF transcript document poses a security risk to transcript recipients. Digitally signing PDF documents (or even the transcripts that contain them) does not help transcript recipients to evaluate the safety of executing any embedded programs or plug-ins. The primary purpose of using PDF is to present static transcript information in an attractive format for human review. Because this limited purpose is admirably served without embedding executable elements in PDF files, any risk posed by their inclusion is unwarranted. Accordingly, transcript originators MUST NOT include in a PDF display transcript any executable scripts or external plug-in references. In order to preclude execution of untrusted programs on their local system, transcript recipients SHOULD use only trusted tools to process and view display transcripts.
以前の研究[RFC3778]は、PDFをMIMEメディアタイプとして使用することから生じるセキュリティの考慮事項を識別しています。これらの考慮事項の1つは、PDF文書に実行可能な「スクリプト」または外部の実行可能なプラグインモジュールへの参照が含まれている可能性があることです。 PDFトランスクリプトドキュメントに任意の実行可能プログラム（またはそれへの参照）を含めることは、トランスクリプト受信者にセキュリティリスクをもたらします。 PDFドキュメント（またはそれらを含むトランスクリプト）にデジタル署名するだけでは、トランスクリプトの受信者が埋め込みプログラムやプラグインの実行の安全性を評価するのに役立ちません。 PDFを使用する主な目的は、静的な筆記録情報を魅力的な形式で人間が確認できるように提示することです。この限定された目的は、実行可能要素をPDFファイルに埋め込むことなく見事に提供されるため、それらを含めることによってもたらされるリスクは保証されません。したがって、トランスクリプトのオリジネーターは、PDFディスプレイのトランスクリプトに実行可能スクリプトや外部プラグイン参照を含めてはなりません。ローカルシステムで信頼できないプログラムが実行されないようにするために、トランスクリプトの受信者は、信頼できるツールのみを使用して、ディスプレイのトランスクリプトを処理および表示する必要があります。
The representation of a display school transcript SHOULD NOT include any header fields beyond those enumerated in the specification for the format of MIME message bodies [RFC2045].
ディスプレイスクールトランスクリプトの表現には、MIMEメッセージ本文の形式の仕様[RFC2045]で列挙されているもの以外のヘッダーフィールドを含めないでください。
A signed school transcript is a MIME body part whose form corresponds to that of a signed OpenPGP/MIME message, as described in section 5 of the OpenPGP/MIME specification [RFC3156]. Accordingly, the MIME content type of a signed school transcript is "multipart/signed", and its form reflects the traditional use of multipart MIME structures to secure email communication [RFC1847]. Thus, the body of a signed school transcript comprises exactly two parts, as illustrated in Figure 6. The first part of the signed transcript body conveys the transcript content, in MIME canonical format, including an appropriate set of MIME content headers. The form and interpretation of the transcript content is described in Section 4 above. The second part of the signed transcript body is the school transcript signature. The signature part represents the OpenPGP digital signature of the transcript originator as it has been applied to the transcript content conveyed by the first part of the signed transcript. The transcript signature is assigned the content type "application/pgp-signature". Transcript recipients MUST reject transcripts that are not validly signed pursuant to the specification for OpenPGP signatures [RFC3156].
署名された学校の筆記録は、OpenPGP / MIME仕様[RFC3156]のセクション5で説明されているように、署名されたOpenPGP / MIMEメッセージの形式に対応するMIME本文部分です。したがって、署名された学校の筆記録のMIMEコンテンツタイプは「multipart / signed」であり、その形式は、電子メール通信を保護するためのマルチパートMIME構造の従来の使用法を反映しています[RFC1847]。したがって、署名された学校の筆記録の本文は、図6に示すように正確に2つの部分で構成されます。署名された筆記録の本文の最初の部分は、適切なMIMEコンテンツヘッダーのセットを含む、MIME正規形式で筆記録コンテンツを伝えます。筆記録コンテンツの形式と解釈については、上記のセクション4で説明しています。署名済み筆記録本体の2番目の部分は、学校の筆記録の署名です。署名部分は、署名された筆記録の最初の部分によって伝達される筆記録コンテンツに適用されているため、筆記録作成者のOpenPGPデジタル署名を表します。文字起こしの署名には、コンテンツタイプ「application / pgp-signature」が割り当てられます。トランスクリプトの受信者は、OpenPGP署名の仕様[RFC3156]に従って有効に署名されていないトランスクリプトを拒否する必要があります。
+--------------------------------------------------+
| SIGNED TRANSCRIPT |
| Content-Type: multipart/signed |
| |
| +-------------------------------------------+ |
| | TRANSCRIPT CONTENT | |
| | Content-Type: multipart/mixed | |
| | | |
| | Body represents transcript content | |
| +-------------------------------------------+ |
| |
| +-------------------------------------------+ |
| | TRANSCRIPT SIGNATURE | |
| | Content-Type: application/pgp-signature | |
| | | |
| | Body represents OpenPGP signature over | |
| | transcript content | |
| +-------------------------------------------+ |
+--------------------------------------------------+
Figure 6: MIME Structure of Signed Transcript
図6：署名済みトランスクリプトのMIME構造
With the sole exception of the "Content-Type" header, the MIME content headers for each signed school transcript MUST correspond exactly to those for the embedded transcript content, as described above in Section 4. For a signed school transcript, the value of the "Content-Type" header MUST be "multipart/signed", its parameters MUST conform to those described in Section 5 of the MIME/OpenPGP specification [RFC3156], and the value of the "boundary" parameter shall, of course, differ from all other boundary parameter values within the same message. Figure 7 presents example headers for a signed school transcript. Although the allowed headers may appear in any order, transcript recipients MUST reject signed transcripts for which the set of included headers differs from the set of headers associated with the embedded transcript content.
「Content-Type」ヘッダーを除いて、各署名済み学校筆記録のMIMEコンテンツヘッダーは、セクション4で説明したように、埋め込まれた筆記録コンテンツのヘッダーと正確に対応している必要があります。署名済み学校の筆記録の場合、 「Content-Type」ヘッダーは「multipart / signed」である必要があり、そのパラメーターはMIME / OpenPGP仕様[RFC3156]のセクション5で説明されているものに準拠する必要があり、「boundary」パラメーターの値は、同じメッセージ内の他のすべての境界パラメーター値。図7は、署名済みの学校成績証明書のヘッダーの例を示しています。許可されたヘッダーは任意の順序で表示されますが、トランスクリプト受信者は、インクルードヘッダーのセットが埋め込みトランスクリプトコンテンツに関連付けられたヘッダーのセットと異なる署名付きトランスクリプトを拒否する必要があります。
Content-Type: multipart/signed;
protocol="application/pgp-signature";
micalg="pgp-sha256";
boundary="===============AAAAAAAAAA=="
MIME-Version: 1.0
Content-Description: Official School Transcript for Hermione Granger
Subject: Official School Transcript for Hermione Granger
From: Transcript Authority at Hogwarts School
<transcript-authority@hogwarts.edu.example>
Organization: Hogwarts School for Witchcraft and Wizardry
Eesst-Version: 1.0
Date: Fri, 22 Mar 2013 09:55:06 -0600
--===============AAAAAAAAAA==
Content-Type: multipart/mixed; boundary="===============BBBBBBBBBB=="
MIME-Version: 1.0
Content-Description: Official School Transcript for Hermione Granger
... Transcript Content as illustrated in Figure 4 ...
--===============BBBBBBBBBB==--
--===============AAAAAAAAAA==
Content-Type: application/pgp-signature; name="signature.asc"
MIME-Version: 1.0
Content-Description: OpenPGP signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQEcBAABAgAGBQJRmkkLAAoJEBzD54azv/d4j4gH/1Aj8poEHLsEhxdv26H76URX
...
8/SQRZGUGUC0xSej5uQMVI59Yriy3dedlzib7EadK6fnz70SsEzUcQy5lHFkNNA=
=8QLW
-----END PGP SIGNATURE-----
--===============AAAAAAAAAA==--
Figure 7: Example Signed School Transcript
図7：署名された学校の筆記録の例
The "Eesst-Version" header serves a crucial if non-obvious purpose for protocol implementors. The presence of this header unambiguously distinguishes a signed school transcript from elements of an enveloping email message by which that transcript may be conveyed.
"Eesst-Version"ヘッダーは、プロトコル実装者にとって明白ではないが重要な目的に役立ちます。このヘッダーの存在は、署名された学校の筆記録を、その筆記録を伝えることができるエンベロープメールメッセージの要素と明確に区別します。
For good reason, the format defined here for signed school transcripts intentionally shares many characteristics with the standard format for OpenPGP/MIME messages [RFC3156]. This similarity not only admits some code reuse within recipient implementations, but, most importantly, also allows transcript recipients to inspect, verify, and extract received school transcripts using existing, widely deployed email clients.
正当な理由により、ここで署名された学校の筆記録用に定義された形式は、OpenPGP / MIMEメッセージの標準形式[RFC3156]と多くの特性を意図的に共有しています。この類似性により、受信者の実装内でのコードの再利用が認められるだけでなく、最も重要なこととして、成績証明書の受信者は、広く展開されている既存の電子メールクライアントを使用して、受信した学校の成績証明書を検査、検証、および抽出できます。
However, the formal similarity between signed school transcripts and generic signed messages can complicate recipient implementations of the transcript exchange protocol, because every signed body part must be fully evaluated to determine its status. When a signed school transcript is conveyed to its recipient enclosed within a signed OpenPGP email message, both transcript and conveying message share the common MIME type "multipart/signed". Moreover, both signed transcript and its conveying message share a common, high-level structure comprising exactly two MIME body parts, independently representing the signed content and the applied digital signature. When a "multipart/signed" MIME body part is encountered as part of a received email message, should that body part be construed as a proper signed school transcript, a signed email message by which a school transcript is conveyed, ill-formed school transcript, or something else altogether? Without additional information, unambiguously answering these questions requires that every signed body part be fully verified, parsed, validated, and checked, because, absent additional information, a receiving implementation cannot know what tests need to be applied.
ただし、署名された学校の成績証明書と一般的な署名付きメッセージの形式的な類似性により、成績証明書交換プロトコルの受信者の実装が複雑になる可能性があります。署名された学校の筆記録が、署名されたOpenPGP電子メールメッセージに囲まれた受信者に伝達されると、筆記録と伝達メッセージの両方が共通のMIMEタイプ「multipart / signed」を共有します。さらに、署名されたトランスクリプトとその伝達メッセージは、署名されたコンテンツと適用されたデジタル署名を個別に表す、正確に2つのMIMEボディパーツで構成される共通の高レベルの構造を共有します。受信した電子メールメッセージの一部として「マルチパート/署名付き」のMIMEボディパートが検出された場合、そのボディパートは適切な署名済みの学校の筆記録、つまり学校の筆記録が伝えられる不正な学校の筆記録として解釈されるべきか、または他に何か他に？追加情報がない場合、これらの質問に明確に答えるには、すべての署名済みのボディパーツを完全に検証、解析、検証、およびチェックする必要があります。追加情報がないと、受信側の実装は適用する必要があるテストを認識できないためです。
Thus, the "Eesst-Version" header serves at least two important functions. Most obviously, this header identifies what version of the EESST format has been applied in preparation of the relevant transcript. Although, currently, the only acceptable version of the EESST format is 1.0, to deny even the possibility of future protocol evolution is to deny the lessons of history. Less obviously, the "Eesst-Version" header allows simple, unambiguous detection of signed school transcripts while still allowing transcript recipients to validate and review school transcripts using familiar, widely available email clients. For these reasons, the "Eesst-Version" header MUST be included in signed school transcripts and their content component, but, in order to most fully realize its value as syntactic disambiguator, the "Eesst-Version" header MUST NOT appear anywhere else.
したがって、「Eesst-Version」ヘッダーは少なくとも2つの重要な機能を果たします。最も明らかに、このヘッダーは、関連する筆記録の準備で適用されたEESST形式のバージョンを識別します。現在、EESST形式の唯一の許容バージョンは1.0ですが、将来のプロトコルの進化の可能性を否定することは、歴史の教訓を否定することです。それほど明確ではありませんが、「Eesst-Version」ヘッダーを使用すると、署名された学校の筆記録を簡単かつ明確に検出できると同時に、筆記録の受信者は使い慣れた広く利用可能なメールクライアントを使用して学校の筆記録を検証および確認できます。これらの理由により、「Eesst-Version」ヘッダーは署名済みの学校の筆記録とそのコンテンツコンポーネントに含める必要がありますが、構文の明確化としての値を最も完全に実現するには、「Eesst-Version」ヘッダーを他の場所に表示しないでください。
Provided that the transcript originator is prohibited from disclosing personal information without student consent, use of the EESST protocol empowers each student to limit sharing of his or her own school transcript to recipients chosen by that student. The design of the protocol not only protects the confidentiality of transcript content in transit but also increases the cost of surveillance by the school or other interested parties of the student's interactions with colleges, prospective employers, or other third parties.
筆記録作成者が学生の同意なしに個人情報を開示することが禁止されている場合、EESSTプロトコルを使用すると、各学生は自分の学校の筆記録の共有を、その学生が選択した受信者に制限できます。プロトコルの設計は、輸送中の筆記録コンテンツの機密性を保護するだけでなく、学校やその他の利害関係者による学生と大学、将来の雇用主、またはその他の第三者とのやり取りの監視コストを増加させます。
A student may convey his signed school transcript to his chosen recipient using any medium or technology that is agreeable to them both. For example, a student may copy his signed digital transcript onto a CD-ROM storage disk and send that physical medium to his intended recipient via a postal mail service. However, because email will frequently be the most convenient means for students to distribute their transcripts, this specification defines a common email format by which each student may privately convey his/her signed school transcript to each recipient. A common form for transcript transmission simplifies implementations of the transcript exchange protocol and fosters their interoperability. A common format allows high-volume transcript recipients to automate decryption and validation of received transcripts as well as their preparation for subsequent review and analysis. A common format that derives from existing email standards allows low-volume transcript recipients to use popular email client software to receive, decrypt, validate, and review transcripts.
生徒は、署名された学校の成績証明書を、選択した受信者に、両方に適したメディアまたはテクノロジーを使用して伝えることができます。たとえば、学生は署名されたデジタルトランスクリプトをCD-ROMストレージディスクにコピーし、その物理メディアを郵便サービスを介して目的の受信者に送信できます。ただし、電子メールは学生が筆記録を配布するための最も便利な手段であることが多いため、この仕様では、各学生が署名済みの学校の筆記録を各受信者に非公開で送信できる共通の電子メール形式を定義します。筆記録送信の一般的な形式は、筆記録交換プロトコルの実装を簡素化し、それらの相互運用性を促進します。共通のフォーマットにより、大量の筆記録の受信者は、受信した筆記録の復号化と検証、およびその後のレビューと分析のための準備を自動化できます。既存の電子メール標準から派生した一般的な形式により、少量の筆記録受信者は一般的な電子メールクライアントソフトウェアを使用して筆記録を受信、復号化、検証、および確認できます。
When a student conveys his transcript to a recipient via email, that student's confidential transcript information is vulnerable to interception and disclosure. In order to mitigate this threat, this specification generally requires that the conveying email message be encrypted as described in the OpenPGP standard [RFC3156]. Every transcript recipient MUST be prepared to accept all transcript transmissions that are encrypted as described in any of the sections below. A student SHOULD use either the encrypted transmission format (Section 6.1) or the encrypted and signed transmission format (Section 6.2), if he or she independently trusts that the transmitting computer will correctly transmit his or her transcript according to the OpenPGP/MIME specification without disclosing its plaintext content. Otherwise, students MAY use the encrypted file transmission format (Section 6.3) or traditional inline transmission format (Section 6.4) below. These latter formats simplify using a more trusted computer to encrypt a student's transcript and later transferring its encrypted form to a less trusted computer for transmission to the chosen recipient.
生徒が筆記録を受信者に電子メールで送信すると、その生徒の秘密の筆記録情報は傍受や開示に対して脆弱になります。この脅威を軽減するために、この仕様では一般に、OpenPGP標準[RFC3156]で説明されているように、伝達する電子メールメッセージを暗号化する必要があります。以下のいずれかのセクションで説明するように、すべての筆記録の受信者は、暗号化されたすべての筆記録の送信を受け入れる準備ができていなければなりません。学生は、送信側のコンピューターがOpenPGP / MIME仕様に従って自分の筆記録を正しく送信することを自分で信頼している場合、暗号化された送信形式（6.1節）または暗号化および署名された送信形式（6.2節）のいずれかを使用する必要があります（SHOULD）平文の内容を開示する。それ以外の場合、学生は以下の暗号化されたファイル転送形式（セクション6.3）または従来のインライン転送形式（セクション6.4）を使用できます。後者の形式では、より信頼性の高いコンピューターを使用して学生の筆記録を暗号化し、後でその暗号化されたフォームを信頼性の低いコンピューターに転送して、選択した受信者に送信します。
Because transcript transmissions must be encrypted in order to assure student privacy, every potential transcript recipient MUST generate an OpenPGP key pair and publish its public component for use by students in the preparation of those transmissions. The public key for each transcript recipient should be published (together with its OpenPGP fingerprint) on the web page for that recipient or in the global OpenPGP key database. To protect the privacy of personal information transmitted to each chosen recipient, a student need only retrieve the published key for that recipient and use it to encrypt the transcript transmission.
受講者のプライバシーを保証するために筆記録の送信は暗号化する必要があるため、潜在的な筆記録の受信者はOpenPGP鍵ペアを生成し、それらの送信の準備で学生が使用できるように公開コンポーネントを公開する必要があります。各筆記録受信者の公開鍵は、その受信者のWebページまたはグローバルOpenPGP鍵データベースで（OpenPGPフィンガープリントと共に）公開する必要があります。選択した各受信者に送信される個人情報のプライバシーを保護するために、学生はその受信者の公開鍵を取得し、それを使用して筆記録の送信を暗号化するだけで済みます。
With some effort, however, an attacker could, by masquerading as a legitimate transcript recipient, perhaps trick a student into transmitting private information to the attacker, encrypted in a key that is known to the attacker. In order to protect student privacy in the face of such attacks, a transcript recipient should resist successful forgery of his/her OpenPGP identity by asking other trustworthy individuals (e.g., respected colleagues or institutional officers) to certify that identity. An OpenPGP identity is certified by affixing another's digital signature to the associated OpenPGP key (see Section 12 of the OpenPGP message format specification [RFC4880] and Section 3 in the GNU Privacy Handbook [GPH]). Those who sign a recipient's public key are implicitly vouching for the association between that key and the true identity of the recipient. Consistent with the view that the student bears primary responsibility for the privacy of his/her transcript information, the student is ultimately responsible for evaluating the authenticity of public keys that he/ she uses to encrypt that information while in transit. Adding certifying signatures to a recipient's key reduces the chance that a student could be deceived by an imposter.
しかし、攻撃者は何らかの努力をして、正当な筆記録の受信者になりすますことにより、学生をだまして、攻撃者に知られているキーで暗号化された個人情報を攻撃者に送信させることができます。そのような攻撃に直面して学生のプライバシーを保護するために、筆記録の受信者は、他の信頼できる個人（たとえば、尊敬される同僚や機関の役員）にその身元を証明するよう依頼することにより、OpenPGP IDの偽造の成功に抵抗する必要があります。 OpenPGP IDは、関連付けられたOpenPGPキーに他の人のデジタル署名を添付することによって認証されます（OpenPGPメッセージフォーマット仕様[RFC4880]のセクション12およびGNUプライバシーハンドブック[GPH]のセクション3を参照）。受信者の公開鍵に署名する者は、その鍵と受信者の真のアイデンティティとの間の関連付けを暗黙のうちに保証しています。受講者は筆記録情報のプライバシーについて主な責任を負うとの見方に従い、最終的に、受講者は転送中に情報を暗号化するために使用する公開鍵の信頼性を評価する責任があります。証明書の署名を受信者の鍵に追加すると、詐欺師によって学生が騙される可能性が低くなります。
In order to maximize student privacy and autonomy, the operation of this protocol sharply separates the function of transcript creation from the function of transcript transmission. The former function is assigned exclusively to the issuing secondary school (the transcript originator), while the latter function is assigned exclusively to the individual student. Participants in the protocol must behave so as to preserve the privacy afforded by this separation. A transcript originator MUST NOT transmit, share, or distribute a school transcript or any component thereof to any party other than the individual student to whom it pertains. A transcript recipient MUST reject any transcript that seems to have been transmitted by or on behalf of anyone but the student. Although non-student transcript transmission can be difficult to detect reliably, certain transmission characteristics unambiguously suggest abuse of student prerogatives. Accordingly, all recipient implementations MUST detect and reject transcript transmissions with any of the following characteristics:
学生のプライバシーと自律性を最大化するために、このプロトコルの操作は、筆記録作成の機能と筆記録送信の機能を大幅に分離します。前者の機能は発行元の中等学校（筆記録作成者）にのみ割り当てられ、後者の機能は個々の生徒にのみ割り当てられます。プロトコルの参加者は、この分離によって提供されるプライバシーを保護するように行動する必要があります。成績証明書の作成者は、学校の成績証明書またはそのコンポーネントを、それが関係する個々の学生以外の当事者に送信、共有、または配布してはなりません。文字起こしの受信者は、学生以外の誰かが送信した、またはその代わりに送信したと思われる文字起こしを拒否する必要があります。学生以外の筆記録の伝達を確実に検出することは難しい場合がありますが、特定の伝達特性は明白に学生の特権の乱用を示唆しています。したがって、すべての受信者の実装は、次のいずれかの特性を持つ筆記録の送信を検出して拒否する必要があります。
o A transcript recipient MUST reject any transcript that is delivered in the same email message or on the same physical storage medium as any other.
o 文字起こしの受信者は、同じ電子メールメッセージで、または他と同じ物理ストレージメディアで配信される文字起こしを拒否する必要があります。
o A transcript recipient MUST reject any transcript for which the transcript originator and the sender of the transcript transmission are identical.
o 文字起こしの受信者は、文字起こしの発信者と文字起こしの送信者が同一である文字起こしを拒否しなければなりません（MUST）。
o A transcript recipient MUST reject any transcript for which the transcript originator (who signs that transcript) and the signer of the transcript transmission are identical.
o 筆記録の受信者は、筆記録の作成者（筆記録に署名する人）と筆記録の送信者の署名者が同一である筆記録を拒否する必要があります。
o A transcript recipient MUST reject any transcript for which the received transcript transmission is addressed to multiple recipients.
o 文字起こしの受信者は、受信した文字起こしの送信が複数の受信者に宛てられているすべての文字起こしを拒否する必要があります。
In the encrypted transmission format, the signed school transcript is conveyed to a single recipient as a MIME attachment to an OpenPGP encrypted email message. Consistent with Section 4 of the OpenPGP/ MIME specification [RFC3156], the transmission email message must have MIME content type "multipart/encrypted", and, as illustrated in Figure 8, the body of the message must comprise exactly two parts. The first body part must have MIME content type "application/ pgp-encrypted", and its content must include only the literal value "Version: 1" on a line by itself. The second body part must have MIME content type "application/octet-stream". Its content is the result of applying the OpenPGP encryption algorithm to the MIME canonical representation of the relevant signed school transcript.
暗号化された送信形式では、署名された学校の筆記録がOpenPGP暗号化電子メールメッセージへのMIME添付ファイルとして単一の受信者に送信されます。 OpenPGP / MIME仕様[RFC3156]のセクション4に準拠して、送信電子メールメッセージのMIMEコンテンツタイプは「multipart / encrypted」である必要があります。最初のボディパーツはMIMEコンテンツタイプ「application / pgp-encrypted」である必要があり、そのコンテンツには行自体にリテラル値「Version：1」のみを含める必要があります。 2番目の本文部分には、MIMEコンテンツタイプ「application / octet-stream」が必要です。その内容は、OpenPGP暗号化アルゴリズムを、関連する署名済み学校の成績証明書のMIME正規表現に適用した結果です。
+--------------------------------------------------+
| ENCRYPTED TRANSCRIPT TRANSMISSION |
| Content-Type: multipart/encrypted |
| |
| +-------------------------------------------+ |
| | GRATUITOUS TEXTUAL PREAMBLE | |
| | Content-Type: application/pgp-encrypted | |
| | | |
| | Body is literal "Version: 1" | |
| +-------------------------------------------+ |
| |
| +-------------------------------------------+ |
| | ENCRYPTED SIGNED TRANSCRIPT | |
| | Content-Type: application/octet-stream | |
| | | |
| | Body represents OpenPGP encryption of | |
| | signed school transcript | |
| +-------------------------------------------+ |
+--------------------------------------------------+
Figure 8: MIME Structure of Encrypted Transcript Transmission
図8：暗号化されたトランスクリプト送信のMIME構造
In the encrypted and signed transmission format, the signed school transcript is conveyed to a single recipient as an attachment to an OpenPGP encrypted and signed email message. Consistent with Section 6.1 of the OpenPGP/MIME specification [RFC3156], preparation of a message in this format is a two-stage process. During this process, the transcript transmission is, first, digitally signed by the transmitting student and, second, encrypted to protect student information from disclosure to anyone but the lone recipient.
暗号化および署名された送信形式では、署名された学校の筆記録がOpenPGP暗号化および署名された電子メールメッセージの添付ファイルとして単一の受信者に送信されます。 OpenPGP / MIME仕様[RFC3156]のセクション6.1に準拠して、この形式でのメッセージの準備は2段階のプロセスです。このプロセスでは、筆記録の送信は、最初に送信側の学生によってデジタル署名され、次に暗号化されて、学生情報が唯一の受信者以外に開示されないように保護されます。
+--------------------------------------------------+
| SIGNED TRANSCRIPT TRANSMISSION |
| Content-Type: multipart/signed |
| |
| +-------------------------------------------+ |
| | SIGNED TRANSMISSION CONTENT | |
| | Content-Type: multipart/signed | |
| | | |
| | Body is signed school transcript | |
| +-------------------------------------------+ |
| |
| +-------------------------------------------+ |
| | TRANSMISSION SIGNATURE | |
| | Content-Type: application/pgp-signature | |
| | | |
| | Body is OpenPGP signature over signed | |
| | transmission content | |
| +-------------------------------------------+ |
+--------------------------------------------------+
Figure 9: MIME Structure of Signed Transcript Transmission
図9：署名された筆記録のMIME構造
The first stage of preparing an encrypted and signed transcript transmission is applying the student's signature to the transmission content. As illustrated in Figure 9, the resulting MIME body part has content type "multipart/signed" and comprises exactly two parts. The first part is the signed transmission content and corresponds to the signed school transcript in its entirety, whose structure is illustrated in Figure 6. The second part is the transmission signature. Its MIME content type is "application/pgp-signature", and its content is the result of applying the OpenPGP signature algorithm, using the student's private key, to the transmission content, the canonical representation of the signed school transcript, which is already signed by the transcript originator.
暗号化および署名された筆記録の送信を準備する最初の段階は、送信コンテンツに学生の署名を適用することです。図9に示すように、結果のMIMEボディパートはコンテンツタイプ「multipart / signed」を持ち、正確に2つのパートで構成されます。最初の部分は署名された送信コンテンツであり、全体が署名された学校の筆記録に対応します。その構造は図6に示されています。2番目の部分は送信署名です。そのMIMEコンテンツタイプは "application / pgp-signature"であり、そのコンテンツは、学生の秘密鍵を使用してOpenPGP署名アルゴリズムを送信コンテンツに適用した結果です。筆記録者による
+--------------------------------------------------+
| ENCRYPTED TRANSCRIPT TRANSMISSION |
| Content-Type: multipart/encrypted |
| |
| +-------------------------------------------+ |
| | GRATUITOUS TEXTUAL PREAMBLE | |
| | Content-Type: application/pgp-encrypted | |
| | | |
| | Body is literal "Version: 1" | |
| +-------------------------------------------+ |
| |
| +-------------------------------------------+ |
| | ENCRYPTED SIGNED TRANSCRIPT | |
| | Content-Type: application/octet-stream | |
| | | |
| | Body represents OpenPGP encryption of | |
| | signed transcript transmission | |
| +-------------------------------------------+ |
+--------------------------------------------------+
Figure 10: MIME Structure of Encrypted Transcript Transmission
図10：暗号化されたトランスクリプト送信のMIME構造
The second stage of preparing an encrypted and signed transcript transmission is wrapping the result of the first stage into an OpenPGP encrypted message, protecting student information from disclosure to anyone but the lone recipient. As illustrated in Figure 10, the encrypted transcript transmission has the form proscribed in Section 6.1 of the OpenPGP/MIME specification. The MIME content type is "multipart/encrypted" and the result comprises exactly two body parts. The first body part must have MIME content type "application/pgp-encrypted", and its content must include only the literal value "Version: 1" on a line by itself. The second body part must have MIME content type "application/octet-stream". Its content is the result of applying the OpenPGP encryption algorithm to the MIME canonical representation of the relevant signed transcript transmission, which was produced during the first stage of the two-stage process.
暗号化され、署名された筆記録の送信を準備する第2段階では、第1段階の結果をOpenPGP暗号化メッセージにラップし、学生情報を唯一の受信者以外に公開されないように保護します。図10に示すように、暗号化された筆記録の送信形式は、OpenPGP / MIME仕様のセクション6.1で禁止されています。 MIMEコンテンツタイプは「multipart / encrypted」であり、結果は正確に2つのボディパートで構成されます。最初のボディパーツはMIMEコンテンツタイプ "application / pgp-encrypted"である必要があり、そのコンテンツには行自体にリテラル値 "Version：1"のみを含める必要があります。 2番目の本文部分には、MIMEコンテンツタイプ「application / octet-stream」が必要です。その内容は、OpenPGP暗号化アルゴリズムを、関連する署名済みトランスクリプト送信のMIME正規表現に適用した結果であり、2段階プロセスの最初の段階で生成されました。
Privacy protections afforded by the EESST protocol depend upon the assumption that the computer used by the student to transmit his or her school transcript reliably executes the required EESST protocol operations without disclosing confidential information. In particular, the transmitting computer is assumed to prevent any access to the plaintext form of a school transcript by anyone but the student. The hardware and software of the transmitting computer is assumed to be free of any flaws that could weaken the encryption applied to his or her transcript. The transmitting computer is also assumed to send the transcript reliably and directly to each chosen recipient without reporting to any third party either the fact of this transmission or the identity of the recipient. Validating these assumptions can be especially problematic when the student does not unilaterally own and control the transmitting computer.
EESSTプロトコルによって提供されるプライバシー保護は、生徒が学校の成績証明書を送信するために使用するコンピュータが、機密情報を開示することなく必要なEESSTプロトコル操作を確実に実行するという前提に依存します。特に、送信側のコンピュータは、学生以外の誰もがプレーンテキスト形式の学校の筆記録にアクセスできないように想定されています。送信側コンピュータのハードウェアとソフトウェアには、筆記録に適用される暗号化を弱める可能性のある欠陥がないと想定されています。送信側のコンピューターは、この送信の事実または受信者の身元を第三者に報告することなく、選択された各受信者にトランスクリプトを確実かつ直接送信することも想定されています。これらの仮定の検証は、学生が送信側のコンピュータを一方的に所有および制御していない場合に特に問題になります。
Sometimes the computer from which a student must transmit his or her transcript cannot reasonably be trusted. Indeed, some email client implementations manifestly do not permit students to compose a secure email message without sharing private information with either their email provider, system administrator, or other third party. Web-based email clients are perhaps the most obvious and widespread example of intrinsically insecure email platforms: neither cryptographic keys nor plaintext message content can be safely stored or processed on such systems. Another example of intrinsically insecure platforms are computers and email servers provided for student use by schools, to which, as a practical matter, school administrators and technical staff enjoy unrestricted access.
生徒が筆記録を送信する必要があるコンピュータは、適度に信頼できない場合があります。実際、一部の電子メールクライアントの実装では、学生が電子メールプロバイダー、システム管理者、または他の第三者と個人情報を共有せずに安全な電子メールメッセージを作成することを明らかに許可していません。 Webベースの電子メールクライアントは、おそらく本質的に安全でない電子メールプラットフォームの最も明白で広範囲にわたる例です。暗号化キーもプレーンテキストメッセージコンテンツも、そのようなシステムで安全に保存または処理することはできません。本質的に安全ではないプラットフォームのもう1つの例は、学校が生徒が使用するために提供されているコンピューターと電子メールサーバーで、実際には、学校の管理者と技術スタッフが無制限にアクセスできます。
A student may use the encrypted file transmission format when the computer that he or she must use to transmit his or her transcript cannot be trusted to perform the necessary encryption correctly or without disclosing the plaintext transcript. This format simplifies using a more trusted computer to encrypt a student's transcript and later transferring its encrypted form to a less trusted computer for transmission to the chosen recipient.
受講者が自分の筆記録を送信するために使用する必要があるコンピューターが必要な暗号化を正しく実行するために信頼できない場合、またはプレーンテキストの筆記録を開示しない場合、学生は暗号化ファイル送信形式を使用できます。この形式では、信頼性の高いコンピューターを使用して学生の筆記録を暗号化し、後でその暗号化されたフォームを信頼性の低いコンピューターに転送して、選択した受信者に送信できるようにします。
For example, the student may use an implementation of the OpenPGP cryptographic algorithms on a trusted computer to encrypt the plaintext version of his or her signed school transcript, received from the transcript originator. The key used for this encryption is the public OpenPGP key of the intended transcript recipient. The binary file that results from this encryption is then transferred (e.g., via a USB flash drive or networked file transfer protocol) to a less trusted computer for email transmission to the chosen recipient. On this less trusted computer, the student invokes an email client application to compose and send a plaintext email message (for example, see Figure 11) to the recipient that is formatted according to the MIME specification [RFC2045]. The binary file containing the encrypted version of the student transcript is included in the message as a MIME attachment whose content type is "application/octet-stream".
たとえば、学生はOpenPGP暗号化アルゴリズムの実装を信頼できるコンピュータに使用して、筆記録者から受け取った自分の署名済み学校筆記録の平文バージョンを暗号化できます。この暗号化に使用される鍵は、目的の筆記録受信者のOpenPGP公開鍵です。この暗号化の結果として得られるバイナリファイルは、選択された受信者への電子メール送信のために、信頼性の低いコンピューターに（USBフラッシュドライブまたはネットワークファイル転送プロトコルなどを介して）転送されます。信頼性の低いこのコンピューターで、生徒は電子メールクライアントアプリケーションを呼び出して、MIME仕様[RFC2045]に従ってフォーマットされたプレーンテキストの電子メールメッセージ（たとえば、図11を参照）を作成して受信者に送信します。学生の筆記録の暗号化されたバージョンを含むバイナリファイルは、コンテンツタイプが「application / octet-stream」であるMIME添付ファイルとしてメッセージに含まれています。
When the email message is received by the transcript recipient, the MIME attachment containing the encrypted school transcript may be detached and saved as a binary file on the local disk. A local OpenPGP implementation is invoked to decrypt the saved file using the private OpenPGP encryption key generated by the transcript recipient. The process of detaching and decrypting the attached school transcript may be automated by large-volume transcript recipients.
筆記録の受信者が電子メールメッセージを受信すると、暗号化された学校の筆記録を含むMIME添付ファイルが分離され、バイナリファイルとしてローカルディスクに保存されます。ローカルのOpenPGP実装が呼び出され、トランスクリプト受信者によって生成された秘密のOpenPGP暗号化キーを使用して、保存されたファイルを復号化します。添付された学校の成績証明書を切り離して復号化するプロセスは、大量の成績証明書の受信者が自動化できます。
Message-ID: <55650A7F.7090800@granger-dentistry.com.example>
Date: Tue, 26 May 2015 20:06:23 -0400
From: Hermione Granger <hermione@granger-dentistry.com.example>
MIME-Version: 1.0
To: Dean Vernon Wormer <transcript-receiver@faber.edu.example>
Subject: Transmission of School Transcript
Content-Type: multipart/mixed;
boundary="------------010307000006020005010307"
This is a multi-part message in MIME format.
--------------010307000006020005010307
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Dear Dean Wormer:
親愛なるディーン・ワーマー：
Please find attached my high school transcript, encrypted in the public encryption key published by Faber College for transcript transmission. I stored the plaintext signed transcript that I received from my high school on my own secure computer under the filename TrnGranger.eml and encrypted its contents for transmission by invoking the following command:
筆記録を送信するために、Faber Collegeによって公開された公開暗号化キーで暗号化された、添付の高校の筆記録を見つけてください。私は高校から受け取った平文の署名済みトランスクリプトを自分の安全なコンピューターにファイル名TrnGranger.emlで保存し、次のコマンドを呼び出して送信用にコンテンツを暗号化しました。
gpg --encrypt --recipient transcript-receiver@faber.edu TrnGranger.eml
The resulting encrypted file, TrnGranger.eml.gpg, is attached to this email message. Save that file to the disk on your local computer and decrypt the transcript by invoking the command:
結果の暗号化されたファイルTrnGranger.eml.gpgは、この電子メールメッセージに添付されます。そのファイルをローカルコンピューターのディスクに保存し、次のコマンドを実行してトランスクリプトを復号化します。
gpg --output TrnGranger.eml --decrypt TrnGranger.eml.gpg
gpg --output TrnGranger.eml --decrypt TrnGranger.eml.gpg
Sincerely, Hermione Granger
心から、ハーマイオニーグレンジャー
--------------010307000006020005010307
Content-Type: application/octet-stream; name="TrnGranger.eml.gpg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="TrnGranger.eml.gpg"
hQEMA4Fu2Js7ulkaAQf/aeiLeoy9L+YddGr0HieHd3KH3wiqLnaImsBaLfboGx+EdTIRn
...
cSJlVDOZKj6nPULT5zqYsfTEHPf+5escZab4J2Rkt/w1BhNDtulNJrbv6q2lk3xBzlt+Z
kQ==
--------------010307000006020005010307--
Figure 11: Encrypted File Transcript Transmission
図11：暗号化されたファイルのトランスクリプト送信
A student may use the traditional inline transmission format when the computer that he or she must use to transmit his or her transcript cannot be trusted to perform the necessary encryption correctly or without disclosing the plaintext transcript. In common with the encrypted file transmission format described above (Section 6.3), the traditional inline format simplifies using a more trusted computer to encrypt a student's transcript and later transferring its encrypted form to a less trusted computer for transmission to the chosen recipient.
受講者は、筆記録の送信に使用する必要があるコンピューターが必要な暗号化を正しく実行するために信頼できない場合、またはプレーンテキストの筆記録を開示しない場合に、従来のインライン送信形式を使用できます。上記の暗号化されたファイル転送形式（セクション6.3）と同様に、従来のインライン形式は、信頼性の高いコンピューターを使用して学生の筆記録を暗号化し、後でその暗号化されたフォームを信頼性の低いコンピューターに転送して、選択した受信者に転送することを簡素化します。
The traditional inline format allows a student to use an implementation of the OpenPGP cryptographic algorithms on a trusted computer to encrypt the plaintext version of his or her signed school transcript, received from the transcript originator. The key used for this encryption is the public OpenPGP key of the intended transcript recipient. The encrypted transcript is represented as an ASCII-armored text file that is then transferred (e.g., via a USB flash drive or networked file transfer protocol) to a less trusted computer for email transmission to the chosen recipient. On this less trusted computer, the student invokes an email client application to compose and send a plaintext email message to the recipient. The content of the ASCII-armored file containing the encrypted version of the student transcript is pasted (or otherwise inserted) into the new email message as the sole content of its body.
従来のインライン形式では、学生がOpenPGP暗号化アルゴリズムの実装を信頼できるコンピューターに使用して、筆記者から受け取った自分の署名済み学校筆記録のプレーンテキストバージョンを暗号化できます。この暗号化に使用される鍵は、目的の筆記録受信者のOpenPGP公開鍵です。暗号化された筆記録は、ASCIIで保護されたテキストファイルとして表され、選択された受信者への電子メール送信のために、信頼性の低いコンピューターに（USBフラッシュドライブやネットワークファイル転送プロトコルなどを介して）転送されます。この信頼性の低いコンピューターで、生徒は電子メールクライアントアプリケーションを呼び出して、プレーンテキストの電子メールメッセージを作成し、受信者に送信します。暗号化された学生の筆記録を含むASCII形式のファイルのコンテンツは、本文の唯一のコンテンツとして新しい電子メールメッセージに貼り付けられます（または挿入されます）。
A traditional inline transcript transmission has the form of a simple email message (in the Internet Message Format [RFC5322]) whose body is exclusively and entirely the encrypted form of the signed school transcript being transmitted. Representation of the included transcript MUST conform to the OpenPGP Message Format specification [RFC4880] for the ASCII-armored encoding of the OpenPGP encryption of the canonical MIME representation of the relevant signed school transcript. An example inline transcript transmission is illustrated in Figure 12.
従来のインライントランスクリプトの送信は、送信される署名された学校のトランスクリプトの暗号化された形式のみが完全に本文である、単純な電子メールメッセージ（インターネットメッセージ形式[RFC5322]の形式）です。含まれる筆記録の表現は、関連する署名済み学校の筆記録の正規MIME表現のOpenPGP暗号化のASCII装甲エンコーディングのOpenPGPメッセージフォーマット仕様[RFC4880]に準拠する必要があります。インライントランスクリプトの送信例を図12に示します。
When the email message is received by the transcript recipient, a local OpenPGP implementation is invoked to extract and decrypt the inline representation of the encrypted school transcript, using the private OpenPGP encryption key generated by the transcript recipient. The process of extracting and decrypting the transmitted school transcript may be automated by large-volume transcript recipients.
トランスクリプト受信者が電子メールメッセージを受信すると、ローカルのOpenPGP実装が呼び出され、トランスクリプト受信者が生成したプライベートOpenPGP暗号化キーを使用して、暗号化された学校のトランスクリプトのインライン表現が抽出および復号化されます。送信された学校の成績証明書を抽出して解読するプロセスは、大量の成績証明書の受信者が自動化できます。
While the traditional inline format is an acceptable method of secure transcript transmission, it is probably best suited to students who lack ready alternatives. Because inline representation of OpenPGP messages can sometimes be incompatible with other email features and conventions, the encrypted file format may be a better alternative for transcript transmissions when the transmitting computer cannot be trusted. A brief essay by Josefsson [Jos07] identifies multiple difficulties that can arise from use of inline OpenPGP, although none is strictly relevant to a correctly formed EESST transcript transmission. Accordingly, the traditional inline format may be used when needed but only with full consideration of its potential limitations on interoperability.
従来のインライン形式は安全な筆記録の受け入れ可能な方法ですが、準備が整っていない生徒にはおそらく最も適しています。 OpenPGPメッセージのインライン表現は他の電子メール機能や規則と互換性がない場合があるため、暗号化されたファイル形式は、送信側のコンピューターが信頼できない場合にトランスクリプトの送信に適しています。 Josefsson [Jos07]による簡単なエッセイは、インラインOpenPGPの使用から生じる可能性のある複数の問題を特定していますが、正しく形成されたEESSTトランスクリプトの送信に厳密に関連するものはありません。したがって、必要に応じて従来のインライン形式を使用できますが、相互運用性に関する潜在的な制限を十分に考慮した上でのみ使用できます。
Return-Path: <hermione@granger-dentistry.com.example>
Delivered-To: transcript-receiver@faber.edu.example
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain
Date: Wed, 3 Jul 2013 12:40:01 -0400
From: Hermione Granger <hermione@granger-dentistry.com.example>
To: Transcript Receiver at Faber College
<transcript-receiver@faber.edu.example>
Subject: Encrypted Inline Transmission of School Transcript
X-Mailer: smtp-cli 3.3, see http://smtp-cli.logix.cz
Content-Transfer-Encoding: 8bit
Message-ID: <1372869801.14441.1.camel@hermione>
-----BEGIN PGP MESSAGE-----
Version: GnuPG v1.4.10 (GNU/Linux)
hQEMA4Fu2Js7ulkaAQf9Fm4+75kE6gQ1T8pjzf4GJhtBqxTTh2AaGtKZkZy9TW8h
zsbSNzZuTVf8QvJRSfk0mZywRG42dilf4Zoygpj3xJgKf7JlCEXnY5m4Luq5hvnW
...
hKgY5Kye/cu/4qwYdFOiljkMR1tv1Avh37OmmcMOZ6Hy9gbdrgQzHsPVWLDQNUYy
jxUAN8thZooRj/jHgq23EZaNyKxD
=Dga7
-----END PGP MESSAGE-----
Figure 12: Traditional Inline Signed Transcript Transmission
図12：従来のインライン署名されたトランスクリプトの送信
The security of the EESST protocol depends upon the security of the OpenPGP protocols on which it is based. Although the cryptographic algorithms included in OpenPGP are among the strongest used in any known protocol, the integrity, authenticity, and confidentiality of conveyed student information is not assured unless EESST protocol implementors and users faithfully observe all requirements and recommendations of the relevant specifications ([RFC4880], [RFC3156], and [RFC4270]). In particular, the SHA-256 digest algorithm and RSA key lengths of at least 2048 bits MUST be used. Happily, these are supported by all major OpenPGP implementations.
EESSTプロトコルのセキュリティは、そのベースとなっているOpenPGPプロトコルのセキュリティに依存します。 OpenPGPに含まれる暗号化アルゴリズムは既知のプロトコルで最も強力に使用されていますが、EESSTプロトコルの実装者とユーザーが関連する仕様のすべての要件と推奨事項を忠実に守らない限り、伝達される学生情報の完全性、信頼性、機密性は保証されません（[RFC4880 ]、[RFC3156]、および[RFC4270]）。特に、SHA-256ダイジェストアルゴリズムと少なくとも2048ビットのRSAキー長を使用する必要があります。幸いなことに、これらはすべての主要なOpenPGP実装でサポートされています。
The authority and integrity of generated school transcripts depend on the continued secrecy of the private cryptographic key by which those transcripts are signed. For greatest security, the guidance director should be physically present when and where the computer program is invoked to generate and sign the transcripts.
生成された学校の筆記録の権限と完全性は、それらの筆記録に署名するための秘密暗号鍵の継続的な機密性に依存します。最高のセキュリティを確保するために、ガイダンスディレクターは、トランスクリプトを生成して署名するためにコンピュータープログラムが呼び出されるときと場所に物理的に存在する必要があります。
When an OpenPGP public-private key pair is generated for use by a transcript originator, a key revocation certificate should also be generated and securely stored. In the event that the generated key pair is compromised, the stored revocation certificate may be used to notify others to reject subsequent uses of that key.
トランスクリプトの作成者が使用するOpenPGP公開鍵と秘密鍵のペアが生成される場合、鍵失効証明書も生成され、安全に保管される必要があります。生成されたキーペアが危険にさらされた場合、保存されている失効証明書を使用して、そのキーの以降の使用を拒否するよう他のユーザーに通知できます。
The public cryptographic key for each transcript originator should be published (together with its OpenPGP fingerprint) on the web page for the originating institution and/or in the global OpenPGP key database. Instructions for retrieving and validating the originator's public key should be included in the preface of all issued transcripts.
各筆記録作成者の公開暗号鍵は、発信機関のWebページおよび/またはグローバルOpenPGP鍵データベースで（OpenPGPフィンガープリントと共に）公開する必要があります。発行者の公開鍵を取得して検証する手順は、発行されたすべての筆記録の序文に含める必要があります。
An association of school guidance professionals may wish to publish an online collection of OpenPGP public keys submitted by their members. A college admissions officer (or other high-volume transcript recipient) could then download and import this key collection into a local key database for use in verifying received transcripts.
学校指導専門家の協会は、メンバーが提出したOpenPGP公開鍵のオンラインコレクションの公開を希望する場合があります。大学入試担当者（または他の大量の筆記録の受信者）は、受け取った筆記録の検証に使用するために、この鍵コレクションをダウンロードしてローカル鍵データベースにインポートできます。
In order to reduce the chance that an imposter might successfully masquerade as a particular transcript originator and substitute a false key for the authentic one, the identification of each transcript originator with a particular OpenPGP key should be certified by other well-known, trustworthy officials. To this end, the public key for a transcript originator should be signed by other officials of the originating secondary school, e.g., its principal, senior faculty, or local school board members. The OpenPGP public keys of these certifying officials should be published.
なりすましが特定の筆記録発信者になりすまし、本物の鍵の代わりに偽の鍵を使用する可能性を減らすために、特定のOpenPGP鍵による各筆記録発信者の識別は、他の有名な信頼できる公務員によって証明される必要があります。このため、筆記録者の公開鍵は、元の中等学校の他の職員、たとえば校長、上級教員、または地元の教育委員会のメンバーが署名する必要があります。これらの認証担当者のOpenPGP公開鍵を公開する必要があります。
The public cryptographic key for each transcript recipient should be published (together with its OpenPGP fingerprint) on the web page for the receiving institution and/or in the global OpenPGP key database.
筆記録の各受信者の公開暗号鍵は、受信機関のWebページおよび/またはグローバルOpenPGP鍵データベースで（そのOpenPGPフィンガープリントと共に）公開する必要があります。
The cryptographic operations upon which the security properties of this protocol depend must be performed in private by the relevant stakeholder. The confidentiality of a student's personal transcript information cannot be sustained if others enjoy unauthorized access to that content during the process of encryption. The integrity of an originator's signature on each transcript cannot be assured if others can learn the originator's secret key by observing the signature process. The confidentiality of personal information sent by many students to a particular transcript recipient cannot be assured if others can learn that recipient's secret key by observing the decryption of received transcripts. Therefore, every stakeholder should perform the cryptographic operations proscribed here only when present at a physically isolated computer that is entirely controlled by that stakeholder and that locally stores all keys and confidential information. Using "thin clients" or web-based computing to perform sensitive cryptographic operations forfeits whatever protections this protocol might have otherwise afforded.
このプロトコルのセキュリティプロパティが依存する暗号化操作は、関連する利害関係者が秘密裏に実行する必要があります。暗号化の過程で他の人がコンテンツへの不正アクセスを楽しんだ場合、学生の筆記録情報の機密性は維持できません。他の人が署名プロセスを観察することによって発信者の秘密鍵を知ることができる場合、各筆記録の発信者の署名の完全性は保証できません。多くの学生が特定の筆記録の受信者に送信する個人情報の機密性は、受信した筆記録の復号化を観察することによって受信者の秘密鍵を他人が知ることができる場合は保証できません。したがって、すべての関係者は、ここで禁止されている暗号化操作を、関係者によって完全に制御され、すべてのキーと機密情報をローカルに保存する物理的に隔離されたコンピュータにいる場合にのみ実行する必要があります。 「シンクライアント」またはWebベースのコンピューティングを使用して機密の暗号化操作を実行すると、このプロトコルが提供していた保護がすべて失われます。
Recipient implementations should not reply automatically or routinely to received transcript transmissions. Such replies could provide valuable feedback to an attacker, especially if they can be elicited at will.
受信者の実装は、受信した筆記録の送信に対して自動的または定期的に応答しないでください。このような返信は、特に意のままに引き出せる場合は、攻撃者に貴重なフィードバックを提供する可能性があります。
The EESST exchange format is compatible with and entails no alterations to existing email standards. Indeed, the syntactic similarity between the exchange format and standardized email message formats empowers users to apply widely deployed email tools to verify, interpret, or otherwise manipulate secondary school transcripts.
EESST交換フォーマットは、既存の電子メール規格と互換性があり、変更を必要としません。実際、交換形式と標準化された電子メールメッセージ形式の構文上の類似性により、ユーザーは、広く展開されている電子メールツールを適用して、中等学校の成績証明書を検証、解釈、または操作することができます。
In the hope of preventing any incompatibilities that could arise from future standards evolution or changes in common usage, this section describes the registration of two message header fields that are used in the EESST exchange format but currently lack any formal definition in existing standards. Consistent with registration procedures defined in RFC 3864 [RFC3864], the subsections below describe additions to the "Message Headers" registry maintained by the Internet Assigned Numbers Authority.
将来の標準の進化または一般的な使用法の変更から生じる可能性のある非互換性を防ぐために、このセクションでは、EESST交換フォーマットで使用されているが、現在の既存の標準では正式な定義がない2つのメッセージヘッダーフィールドの登録について説明します。 RFC 3864 [RFC3864]で定義されている登録手順に準拠して、以下のサブセクションでは、インターネット割り当て番号機関によって維持される「メッセージヘッダー」レジストリへの追加について説明します。
The "Eesst-Version" message header field is completely internal to the EESST transcript format, and, indeed, explicitly precluded from appearing within an enveloping email message (see Section 5). Registration has been completed in order to discourage its use in other contexts.
「Eesst-Version」メッセージヘッダーフィールドは、完全にEESSTトランスクリプト形式の内部にあり、実際に、エンベロープ電子メールメッセージ内に表示されないよう明示的に除外されています（セクション5を参照）。他の状況での使用を阻止するために、登録は完了しています。
Header field name: Eesst-Version
ヘッダーフィールド名：Eesst-Version
Applicable protocol: mail
該当するプロトコル：メール
Status: provisional
ステータス：暫定
Author/Change controller: James R. Davin
info@eesst.org
http://www.eesst.org
Specification document(s): RFC 7681
仕様書：RFC 7681
Related information: The value of this header field identifies the version of the EESST exchange format to which the represented school transcript conforms. This header may appear only within EESST school transcripts.
関連情報：このヘッダーフィールドの値は、表現された学校の成績証明書が準拠するEESST交換形式のバージョンを識別します。このヘッダーは、EESST学校の成績証明書内にのみ表示されます。
The EESST exchange format entails use of the "Organization" message header field to identify the originating institution for a student transcript. A header field of this name and semantics is already defined for use within network news articles (see [RFC5536]). Moreover, the "Organization" header field also frequently appears in electronic mail messages, although, perhaps surprisingly, it currently lacks any explicit, written definition in that context. This registration publicly documents ongoing use of this header field and may discourage incompatible uses in future.
EESST交換フォーマットでは、「Organization」メッセージヘッダーフィールドを使用して、学生の筆記録の発信機関を識別します。この名前とセマンティクスのヘッダーフィールドは、ネットワークニュース記事内で使用するためにすでに定義されています（[RFC5536]を参照）。さらに、「Organization」ヘッダーフィールドも電子メールメッセージに頻繁に表示されますが、おそらく驚くべきことに、現在、そのコンテキストでの明確な書面による定義はありません。この登録により、このヘッダーフィールドの継続的な使用が公に文書化され、将来、互換性のない使用が妨げられる可能性があります。
Header field name: Organization
ヘッダーフィールド名：組織
Applicable protocol: mail
該当するプロトコル：メール
Status: informational
ステータス：情報
Author/Change controller: James R. Davin
info@eesst.org
http://www.eesst.org
Specification document(s): RFC 7681
仕様書：RFC 7681
Related information: The value of this header field identifies the organization or institution to which the originator of the relevant message belongs.
関連情報：このヘッダーフィールドの値は、関連するメッセージの発信者が所属する組織または機関を識別します。
Note: this field is quite distinct from the mail address fields MTS.OrganizationName and MTS.OrganizationalUnitNames used in X.400 mail.
注：このフィールドは、X.400メールで使用されるメールアドレスフィールドMTS.OrganizationNameおよびMTS.OrganizationalUnitNamesとはまったく異なります。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[Fun12a] Funck, J., "XML Schema for the PESC Format for Academic Record Data Elements, Version 1.7.0", June 2012, <http://www.pesc.org/library/docs/standards/ High%20School%20Transcript/AcademicRecord_v1.7.0.xsd>.
[Fun12a] Funck、J。、「学術記録データ要素のPESC形式のXMLスキーマ、バージョン1.7.0」、2012年6月、<http://www.pesc.org/library/docs/standards/ High％20School ％20Transcript / AcademicRecord_v1.7.0.xsd>。
[Fun12b] Funck, J., "XML Schema for the PESC Format for High School Transcripts, Version 1.3.0", June 2012, <http://www.pesc.org/library/docs/standards/ High%20School%20Transcript/ HighSchoolTranscript_v1.3.0.xsd>.
[Fun12b] Funck、J。、「高校の筆記録のPESC形式のXMLスキーマ、バージョン1.3.0」、2012年6月、<http://www.pesc.org/library/docs/standards/ High％20School％ 20Transcript / HighSchoolTranscript_v1.3.0.xsd>。
[GPH] Ashley, J., "The GNU Privacy Handbook", 1999, <https://www.gnupg.org/gph/en/manual.pdf>.
[GPH]アシュリー、J。、「The GNU Privacy Handbook」、1999、<https://www.gnupg.org/gph/en/manual.pdf>。
[Jos07] Josefsson, J., "Inline OpenPGP Considered Harmful", April 2007, <http://josefsson.org/ inline-openpgp-considered-harmful.html>.
[Jos07] Josefsson、J。、「有害なインラインOpenPGPと見なされる」、2007年4月、<http://josefsson.org/ inline-openpgp-considered-harmful.html>。
[Mar06] Marton, B., "XML Schema for the PESC Format for Core Main Data Elements, Version 1.2.0", February 2006, <http://www.pesc.org/library/docs/standards/ High%20School%20Transcript/CoreMain_v1.2.0.xml>.
[Mar06] Marton、B.、「コアメインデータ要素のPESC形式のXMLスキーマ、バージョン1.2.0」、2006年2月、<http://www.pesc.org/library/docs/standards/ High％20School ％20Transcript / CoreMain_v1.2.0.xml>。
[PDF17] Adobe Systems, Inc., "Document Management - Portable Document Format - Part 1: PDF 1.7, First Edition", July 2008, <http://wwwimages.adobe.com/www.adobe.com/content/ dam/Adobe/en/devnet/pdf/pdfs/PDF32000_2008.pdf>.
[PDF17] Adobe Systems、Inc。、「Document Management-Portable Document Format-Part 1：PDF 1.7、First Edition」、2008年7月、<http://wwwimages.adobe.com/www.adobe.com/content/dam /Adobe/en/devnet/pdf/pdfs/PDF32000_2008.pdf>。
[RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, DOI 10.17487/RFC1847, October 1995, <http://www.rfc-editor.org/info/rfc1847>.
[RFC1847] Galvin、J.、Murphy、S.、Crocker、S。、およびN. Freed、「MIMEのセキュリティマルチパート：Multipart / SignedおよびMultipart / Encrypted」、RFC 1847、DOI 10.17487 / RFC1847、1995年10月、< http://www.rfc-editor.org/info/rfc1847>。
[RFC1958] Carpenter, B., Ed., "Architectural Principles of the Internet", RFC 1958, DOI 10.17487/RFC1958, June 1996, <http://www.rfc-editor.org/info/rfc1958>.
[RFC1958] Carpenter、B。、編、「インターネットのアーキテクチャの原則」、RFC 1958、DOI 10.17487 / RFC1958、1996年6月、<http://www.rfc-editor.org/info/rfc1958>。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, <http://www.rfc-editor.org/info/rfc2045>.
[RFC2045] Freed、N。およびN. Borenstein、「Multipurpose Internet Mail Extensions（MIME）Part One：Format of Internet Message Bodies」、RFC 2045、DOI 10.17487 / RFC2045、1996年11月、<http：//www.rfc- editor.org/info/rfc2045>。
[RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME Security with OpenPGP", RFC 3156, DOI 10.17487/RFC3156, August 2001, <http://www.rfc-editor.org/info/rfc3156>.
[RFC3156] Elkins、M.、Del Torto、D.、Levien、R。、およびT. Roessler、「OpenPGPを使用したMIMEセキュリティ」、RFC 3156、DOI 10.17487 / RFC3156、2001年8月、<http：//www.rfc -editor.org/info/rfc3156>。
[RFC3778] Taft, E., Pravetz, J., Zilles, S., and L. Masinter, "The application/pdf Media Type", RFC 3778, DOI 10.17487/RFC3778, May 2004, <http://www.rfc-editor.org/info/rfc3778>.
[RFC3778] Taft、E.、Pravetz、J.、Zilles、S。、およびL. Masinter、「The application / pdf Media Type」、RFC 3778、DOI 10.17487 / RFC3778、2004年5月、<http：// www。 rfc-editor.org/info/rfc3778>。
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, DOI 10.17487/RFC3864, September 2004, <http://www.rfc-editor.org/info/rfc3864>.
[RFC3864] Klyne、G.、Nottingham、M。、およびJ. Mogul、「メッセージヘッダーフィールドの登録手順」、BCP 90、RFC 3864、DOI 10.17487 / RFC3864、2004年9月、<http：//www.rfc- editor.org/info/rfc3864>。
[RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes in Internet Protocols", RFC 4270, DOI 10.17487/RFC4270, November 2005, <http://www.rfc-editor.org/info/rfc4270>.
[RFC4270] Hoffman、P。およびB. Schneier、「インターネットプロトコルにおける暗号化ハッシュへの攻撃」、RFC 4270、DOI 10.17487 / RFC4270、2005年11月、<http://www.rfc-editor.org/info/rfc4270> 。
[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, DOI 10.17487/RFC4880, November 2007, <http://www.rfc-editor.org/info/rfc4880>.
[RFC4880] Callas、J.、Donnerhacke、L.、Finney、H.、Shaw、D。、およびR. Thayer、「OpenPGP Message Format」、RFC 4880、DOI 10.17487 / RFC4880、2007年11月、<http：// www.rfc-editor.org/info/rfc4880>。
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, <http://www.rfc-editor.org/info/rfc5321>.
[RFC5321] Klensin、J。、「Simple Mail Transfer Protocol」、RFC 5321、DOI 10.17487 / RFC5321、2008年10月、<http://www.rfc-editor.org/info/rfc5321>。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, <http://www.rfc-editor.org/info/rfc5322>.
[RFC5322] Resnick、P。、編、「インターネットメッセージ形式」、RFC 5322、DOI 10.17487 / RFC5322、2008年10月、<http://www.rfc-editor.org/info/rfc5322>。
[RFC5536] Murchison, K., Ed., Lindsey, C., and D. Kohn, "Netnews Article Format", RFC 5536, DOI 10.17487/RFC5536, November 2009, <http://www.rfc-editor.org/info/rfc5536>.
[RFC5536] Murchison、K.、Ed。、Lindsey、C。、およびD. Kohn、「Netnews Article Format」、RFC 5536、DOI 10.17487 / RFC5536、2009年11月、<http://www.rfc-editor.org / info / rfc5536>。
[Sal84] Saltzer, J., Reed, D., and D. Clark, "End-to-End Arguments in System Design", ACM Transactions on Computer Systems 2(4), DOI 10.1145/357401.357402, November 1984, <http://dx.doi.org/10.1145/357401.357402>.
[Sal84] Saltzer、J.、Reed、D。、およびD. Clark、「システム設計におけるエンドツーエンドの引数」、ACM Transactions on Computer Systems 2（4）、DOI 10.1145 / 357401.357402、1984年11月、<http ：//dx.doi.org/10.1145/357401.357402>。
[Ste12] Stewart, T., "Implementation Guide for the Postsecondary Electronic Standards Council XML Standard Format for the High School Transcript, Version 1.3.0", July 2012, <http://www.pesc.org/library/docs/standards/ High%20School%20Transcript/XML%20HS%20Transcript%20Impl%20 Guide%20Version%201.3.0%202012%2007%2026.pdf>.
[Ste12] Stewart、T。、「高校の筆記録のPostsecondary Electronic Standards Council XML標準フォーマットの実装ガイド、バージョン1.3.0」、2012年7月、<http://www.pesc.org/library/docs/標準/ High％20School％20Transcript / XML％20HS％20Transcript％20Impl％20 Guide％20Version％201.3.0％202012％2007％2026.pdf>。
[XML11] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., Yergeau, F., and J. Cowan, "Extensible Markup Language (XML) 1.1 (Second Edition)", W3C Recommendation REC-xml11-20060816, August 2006, <http://www.w3.org/TR/2006/REC-xml11-20060816>.
[XML11] Bray、T.、Paoli、J.、Sperberg-McQueen、C.、Maler、E.、Yergeau、F.、J。Cowan、「Extensible Markup Language（XML）1.1（Second Edition）」、W3C推奨事項REC-xml11-20060816、2006年8月、<http://www.w3.org/TR/2006/REC-xml11-20060816>。
[XSD] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes Second Edition", W3C Recommendation REC-xmlschema-2-20041028, October 2004, <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
[XSD] Biron、P。およびA. Malhotra、「XML Schema Part 2：Datatypes Second Edition」、W3C勧告REC-xmlschema-2-20041028、2004年10月、<http://www.w3.org/TR/2004 / REC-xmlschema-2-20041028>。
Acknowledgments
謝辞
Derek Atkins, Paul Hoffman, and Werner Koch provided independent reviews of this memo. Fred Baker, Dave Crocker, Keith Moore, and Chris Newman provided comments and questions about drafts of this document.
Derek Atkins、Paul Hoffman、Werner Kochは、このメモの独立したレビューを提供しました。フレッドベイカー、デイブクロッカー、キースムーア、およびクリスニューマンは、このドキュメントのドラフトに関するコメントと質問を提供しました。
Author's Address
著者のアドレス
James R. Davin
ジェームス・R・ダビン
Email: info@EESST.org
URI: http://EESST.org/