GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7681

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
  1. -===============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
     ...
  1. -===============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
  1. -===============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
  1. -===============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  ...
  1. -===============BBBBBBBBBB==–
  1. -===============AAAAAAAAAA==

Content-Type: application/pgp-signature; name="signature.asc"

 MIME-Version: 1.0
 Content-Description: OpenPGP signature
 Content-Disposition: attachment; filename="signature.asc"
  1. —-BEGIN PGP SIGNATURE—–

Version: GnuPG v1.4.10 (GNU/Linux)

 iQEcBAABAgAGBQJRmkkLAAoJEBzD54azv/d4j4gH/1Aj8poEHLsEhxdv26H76URX
     ...
 8/SQRZGUGUC0xSej5uQMVI59Yriy3dedlzib7EadK6fnz70SsEzUcQy5lHFkNNA=
 =8QLW
 -----END PGP SIGNATURE-----
  1. -===============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
  1. ————-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>
  1. —-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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7681.txt · Last modified: 2015/10/24 00:14 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki