diff options
Diffstat (limited to 'doc/rfc/rfc7681.txt')
| -rw-r--r-- | doc/rfc/rfc7681.txt | 2243 |
1 files changed, 2243 insertions, 0 deletions
diff --git a/doc/rfc/rfc7681.txt b/doc/rfc/rfc7681.txt new file mode 100644 index 0000000..a3ad192 --- /dev/null +++ b/doc/rfc/rfc7681.txt @@ -0,0 +1,2243 @@ + + + + + + +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. + + 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. + + 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. + +Copyright Notice + + Copyright (c) 2015 IETF Trust and the persons identified as the + document authors. All rights reserved. + + 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. + + + + + + +Davin Informational [Page 1] + +RFC 7681 EESST Protocol Specification October 2015 + + +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 + +1. Introduction + + 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 + + + +Davin Informational [Page 2] + +RFC 7681 EESST Protocol Specification October 2015 + + + 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 + + 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 + + + +Davin Informational [Page 3] + +RFC 7681 EESST Protocol Specification October 2015 + + + 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. + + 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. + + 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. + + 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 + + + +Davin Informational [Page 4] + +RFC 7681 EESST Protocol Specification October 2015 + + + 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 + + + + + + + + + +Davin Informational [Page 5] + +RFC 7681 EESST Protocol Specification October 2015 + + + 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. + +2. Design Motivation + + 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. + + 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 + + + + +Davin Informational [Page 6] + +RFC 7681 EESST Protocol Specification October 2015 + + + 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]: + + 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 + + + + +Davin Informational [Page 7] + +RFC 7681 EESST Protocol Specification October 2015 + + + the message (see Section 6.1). Errors that are diagnosed + subsequently MUST be reported in a mail message, as discussed in + Section 4.4. + +3. Protocol Overview + + 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.1. Student and Originator + + 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. + + The principal responsibilities of a transcript originator are: + + 1. Generate an OpenPGP key pair that can be used to sign school + transcripts. + + 2. Create and securely store a key revocation certificate for the + signing key pair for possible future use should it be + compromised. + + + + + +Davin Informational [Page 8] + +RFC 7681 EESST Protocol Specification October 2015 + + + 3. Publish on the World Wide Web the public component of the + transcript signing key pair, together with its OpenPGP + fingerprint. + + 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. + + 5. Use the signing key pair to create and digitally sign transcripts + for individual students. + + 6. Present each signed transcript confidentially to the individual + student to which it pertains. + + 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. + + 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.1.1. Transcript Requests + + 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 + + + +Davin Informational [Page 9] + +RFC 7681 EESST Protocol Specification October 2015 + + + 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. + + 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. + +3.2. Student and Recipient + + 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. + + + +Davin Informational [Page 10] + +RFC 7681 EESST Protocol Specification October 2015 + + + 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. + + 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. + + 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. + + 3. Import the OpenPGP public key for each chosen recipient into the + local OpenPGP key database. + + 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. + + 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 + + + +Davin Informational [Page 11] + +RFC 7681 EESST Protocol Specification October 2015 + + + 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. + + 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. + + 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. + + 3. Create a (preferably dedicated) email address and mailbox to + which students may direct transmissions of signed school + transcripts. + + 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. + + 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. + + 6. Assemble a collection of public OpenPGP keys published by + legitimate transcript originators. + + 7. Receive and decrypt transcripts transmitted by students. + + 8. Validate the origin and integrity of each received transcript + using the public OpenPGP key of the relevant transcript + originator. + + 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. + + + + +Davin Informational [Page 12] + +RFC 7681 EESST Protocol Specification October 2015 + + + 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. + +4. Transcript Content + + 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. + + Every representation of transcript content MUST include exactly the + following set of MIME content headers: + + 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-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. + + 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 + + + +Davin Informational [Page 13] + +RFC 7681 EESST Protocol Specification October 2015 + + + 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. + + 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". + + 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. + + 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. + + 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]. + + 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. + + + + + +Davin Informational [Page 14] + +RFC 7681 EESST Protocol Specification October 2015 + + + +--------------------------------------------------+ + | 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 + + + + + + + + + + + + + + + + + + + + + + + +Davin Informational [Page 15] + +RFC 7681 EESST Protocol Specification October 2015 + + + 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 + + + + + +Davin Informational [Page 16] + +RFC 7681 EESST Protocol Specification October 2015 + + +4.1. School Transcript Preface + + 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". + + 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. + + 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]. + +4.2. Computational School Transcript + + 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 + + + + + +Davin Informational [Page 17] + +RFC 7681 EESST Protocol Specification October 2015 + + + 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. + + 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. + + 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 + + "<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. + + + + + +Davin Informational [Page 18] + +RFC 7681 EESST Protocol Specification October 2015 + + + <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 + + Additional restrictions on the use of the PESC XML schema foster + common, unambiguous interpretation and simplified processing of + computational transcripts: + + 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. + + 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. + + + + + + + +Davin Informational [Page 19] + +RFC 7681 EESST Protocol Specification October 2015 + + + 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]. + + 4. Lest the origin and correct handling for a computational + transcript be misunderstood, the value ascribed to the + "DocumentTypeCode" XML element MUST be "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". + + 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. + + 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. + +4.3. Display School Transcript + + 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. + + 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. + + 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 + + + +Davin Informational [Page 20] + +RFC 7681 EESST Protocol Specification October 2015 + + + 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. + + 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. + + 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]. + +5. Signed School Transcript + + 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 + + + +Davin Informational [Page 21] + +RFC 7681 EESST Protocol Specification October 2015 + + + 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]. + + +--------------------------------------------------+ + | 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 + + 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. + + + +Davin Informational [Page 22] + +RFC 7681 EESST Protocol Specification October 2015 + + + 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 + + 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. + + 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 + + + +Davin Informational [Page 23] + +RFC 7681 EESST Protocol Specification October 2015 + + + 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. + + 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. + + 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. + +6. Transcript Transmission + + 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 + + + +Davin Informational [Page 24] + +RFC 7681 EESST Protocol Specification October 2015 + + + school or other interested parties of the student's interactions with + colleges, prospective employers, or other third parties. + + 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. + + 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. + + 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 + + + +Davin Informational [Page 25] + +RFC 7681 EESST Protocol Specification October 2015 + + + retrieve the published key for that recipient and use it to encrypt + the transcript transmission. + + 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. + + 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 A transcript recipient MUST reject any transcript for which the + transcript originator and the sender of the transcript + transmission are identical. + + + +Davin Informational [Page 26] + +RFC 7681 EESST Protocol Specification October 2015 + + + 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 A transcript recipient MUST reject any transcript for which the + received transcript transmission is addressed to multiple + recipients. + +6.1. Encrypted Format + + 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. + + +--------------------------------------------------+ + | 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 + + + + + + + +Davin Informational [Page 27] + +RFC 7681 EESST Protocol Specification October 2015 + + +6.2. Encrypted and Signed Format + + 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. + + +--------------------------------------------------+ + | 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 + + 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. + + + + + + +Davin Informational [Page 28] + +RFC 7681 EESST Protocol Specification October 2015 + + + +--------------------------------------------------+ + | 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 + + 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. + + + + + + + + + + + + + + +Davin Informational [Page 29] + +RFC 7681 EESST Protocol Specification October 2015 + + +6.3. Encrypted File Format + + 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. + + 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. + + 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 + + + +Davin Informational [Page 30] + +RFC 7681 EESST Protocol Specification October 2015 + + + 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". + + 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Davin Informational [Page 31] + +RFC 7681 EESST Protocol Specification October 2015 + + + 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: + + 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: + + 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 + + + + + +Davin Informational [Page 32] + +RFC 7681 EESST Protocol Specification October 2015 + + +6.4. Traditional Inline Format + + 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. + + 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. + + 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. + + 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. + + 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 + + + +Davin Informational [Page 33] + +RFC 7681 EESST Protocol Specification October 2015 + + + 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. + + 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 + +7. Security Considerations + + 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. + + + +Davin Informational [Page 34] + +RFC 7681 EESST Protocol Specification October 2015 + + +7.1. Originator Private Key + + 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. + +7.2. Originator Public Key + + 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. + + 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. + +7.3. Originator Certification + + 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. + +7.4. Recipient Public Key + + 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. + + + + +Davin Informational [Page 35] + +RFC 7681 EESST Protocol Specification October 2015 + + +7.5. Secure Clients + + 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. + +7.6. Automatic Replies + + 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. + +8. IANA Considerations + + 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. + + 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. + + + + + + + +Davin Informational [Page 36] + +RFC 7681 EESST Protocol Specification October 2015 + + +8.1. Registration of Eesst-Version Header + + 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. + + Header field name: 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 + + 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. + +8.2. Registration of Organization Header + + 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. + + Header field name: Organization + + Applicable protocol: mail + + Status: informational + + Author/Change controller: James R. Davin + info@eesst.org + http://www.eesst.org + + + + +Davin Informational [Page 37] + +RFC 7681 EESST Protocol Specification October 2015 + + + Specification document(s): 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. + +9. References + +9.1. Normative References + + [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>. + +9.2. Informative References + + [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>. + + [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>. + + [GPH] Ashley, 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>. + + [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>. + + + + + + + +Davin Informational [Page 38] + +RFC 7681 EESST Protocol Specification October 2015 + + + [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>. + + [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>. + + [RFC1958] Carpenter, B., Ed., "Architectural Principles of the + Internet", RFC 1958, DOI 10.17487/RFC1958, June 1996, + <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>. + + [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>. + + [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>. + + [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>. + + [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>. + + [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>. + + [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, + DOI 10.17487/RFC5321, October 2008, + <http://www.rfc-editor.org/info/rfc5321>. + + + + +Davin Informational [Page 39] + +RFC 7681 EESST Protocol Specification October 2015 + + + [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, + DOI 10.17487/RFC5322, October 2008, + <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>. + + [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>. + + [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>. + + [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>. + + [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>. + +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. + +Author's Address + + James R. Davin + + Email: info@EESST.org + URI: http://EESST.org/ + + + + + + + +Davin Informational [Page 40] + |