RFC 7681
Email Exchange of Secondary School Transcripts
Email Exchange of Secondary School Transcripts ✨
Title block tea 🍵
- Request for Comments: 7681 🎀
- Stream: Independent Submission (so this one came from outside the usual IETF working groups 🧚)
- Author: J. Davin 💅
- Date: October 2015 📅
- Category: Informational 📚 (not a standards-track spec, just good info to know)
- ISSN: 2070-1721
- Obsoletes / Updates: the title block doesn't list anything it obsoletes or updates 🙌
Abstract 💖
okay so a common format makes it way easier to swap secondary school academic transcripts over email 📧 Existing standards get used to stop anyone from messing with transcript content, and to send transcripts straight and securely from each student to the people they picked 🔐 No middlemen, no third-party intervention or surveillance, so this protocol protects student privacy and independence better than what's happening right now. It's giving main character energy for students 👑
Status of This Memo 🌸
This doc is not an Internet Standards Track specification. It's just published for informational purposes 📖
It's a contribution to the RFC Series, independent of any other RFC stream. The RFC Editor chose to publish it at their discretion, and they make no statement about whether it's valuable for implementation or deployment 🤷♀️ Documents the RFC Editor approves for publication are not a candidate for any level of Internet Standard. See Section 2 of RFC 5741 for the deets ✨
Info about the current status, any errata, and how to give feedback on this doc lives 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 doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication of this document. Please read these carefully, bestie, because they describe your rights and restrictions with respect to this doc 🫶
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 . . . . . . . . . . . . . . . . . . . . . . . . 401. Introduction ✨
Okay so let's talk about the old-school way student records got passed around, because honestly it was kind of iconic 💌 Traditional, paper-based sharing of individual student records protects the rights and interests of everyone involved: the secondary school officials who curate the records, the students who are both the subjects and the distributors of their own records, and the college admission officers, prospective employers, and others who receive and review those records with the student's permission. 🎀
Picture it: a graduating student is applying for a job or for college, so she asks the guidance counselor at her school for a transcript of her academic achievements. The counselor prepares a paper record of those achievements and hands it right to her, so she can forward it to whoever she pleases 💅 To stop anyone from forging a transcript, the paper often has marks of authenticity, like an imprint of the school seal or the signature of an authorized school official. To stop anyone from messing with the content, the document is sometimes handed over in a sealed postal envelope that can't easily be opened without people noticing, maybe with tamper-proof tape, signed envelope flaps, or even imprinted wax seals 🕯️ The intact physical seal on the envelope tells the recipient that nothing was altered in transit, and the seals and signatures on the enclosed document tell them it's legit. And the student's privacy? Totally assured, because she can send that sealed transcript to whoever she wants without the school knowing or having to check in first 🦋
+++ / \ / \ / \ Figure 1 caption below
Wait, that line above is not part of the document and should be removed. Here is the correct version of the response:
1. Introduction ✨
Okay so let's talk about the old-school way student records got passed around, because honestly it was kind of iconic 💌 Traditional, paper-based sharing of individual student records protects the rights and interests of everyone involved: the secondary school officials who curate the records, the students who are both the subjects and the distributors of their own records, and the college admission officers, prospective employers, and others who receive and review those records with the student's permission. 🎀
Picture it: a graduating student is applying for a job or for college, so she asks the guidance counselor at her school for a transcript of her academic achievements. The counselor prepares a paper record of those achievements and hands it right to her, so she can forward it to whoever she pleases 💅 To stop anyone from forging a transcript, the paper often has marks of authenticity, like an imprint of the school seal or the signature of an authorized school official. To stop anyone from messing with the content, the document is sometimes handed over in a sealed postal envelope that can't easily be opened without people noticing, maybe with tamper-proof tape, signed envelope flaps, or even imprinted wax seals 🕯️ The intact physical seal on the envelope tells the recipient that nothing was altered in transit, and the seals and signatures on the enclosed document tell them it's legit. And the student's privacy? Totally assured, because she can send that sealed transcript to whoever she wants without the school knowing or having to check in first 🦋
+++
/ \
/\ 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
Now, the traditional process is genuinely great for student privacy and prerogatives 🌸 but it also means the school staff have to do manual work to prepare every single transcript. So some school officials decided to "fix" that with technology in a way that totally wrecks student privacy and shuts students out of their own business 🙈 Figure 1 shows this increasingly common mess. Instead of using standardized, easy-to-get technology to protect the integrity of transmitted student data (the way their own signatures used to protect sealed envelopes), school officials stick themselves, or their agents, right between the student and the transcript recipient. They claim, falsely, that nothing else adequately ensures the confidentiality, origin, and integrity of transcript content or the reliability of transcript transmission. Introducing the "third-party processor" in Figure 1 disrupts what should be private, two-way relationships between students and the people they choose to share with, and it basically says that no technical means a student might use to manage and secure their own communication is legit 😤
Basically, educators and their allied service providers pressure students into a false choice: give up their privacy, or accept the limits of a neglected, mostly manual system. And guess who benefits? Them, at the student's expense 💀 One of those benefits is an educational services industry that didn't need to exist, which mediates communication between students and transcript recipients. That communication would, by the most natural operation of the Internet, be end-to-end. A second consequence of this forced mediation is that the mediators get unchecked control over school records that would otherwise be private and often legally protected. A third is that mediators can harvest candid data about student behavior outside the secondary school domain. Even the most basic details about college and job applications, whether they succeeded or not, individually or in aggregate, can be worth a lot to school officials, college administrators, employers, and marketing people. And although that kind of data has historically been private, it's also more valuable and less well protected by law than internal school records, which is kind of a red flag 🚩
So mediated transcript distribution wrecks student privacy and hands school bureaucrats and their friends privileges they haven't earned, but none of those concessions are needed for automated transcript distribution at all 🧚 As Figure 2 suggests, the concessions built into mediated transcript exchange can be mostly eliminated by the most straightforward automation of the traditional transcript process. Main character energy, honestly ✨
Here's the plan. This memo specifies a common format for exchanging secondary school academic transcripts via electronic mail 💌 Because the format supports digital signatures on transcripts by their originator, a student cannot fabricate or alter transcript information provided by school officials. Because the format supports encrypted transmission of school transcripts, the distribution of each student's information can stay private and under their control. Because the format supports asymmetric cryptography, the origin and integrity of received transcripts can be verified independently by the recipient, and confidential content can be independently recovered by the intended recipient while staying protected from unauthorized access. Because the Internet email protocol provides fail-safe delivery, transcripts reliably reach 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. So a student's need for an authoritative record of their education can't be exploited to restrict or monitor their free and private interactions with colleges, employers, or anyone else 🦋 Students can take back control of their personal information and their relationships with prospective employers and admissions officers, and they can stop anyone from quietly harvesting information about their affairs. Last but not least, most participants in the school transcript exchange protocol don't need specialized software at all: the needs of every student 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
TranscriptsNow let's name things. The acronym EESST (Email Exchange of Secondary School Transcripts) is what we call the format and methods defined here for securely conveying student academic records under student control 🎀 If you're implementing this spec, the requirements are written using a keyword vocabulary [RFC2119] that's widely understood across the Internet community, so you'll know exactly what's expected 🔥
2. Design Motivation ✨
okay so every protocol has to decide which job goes to which participant, and when those participants don't all belong to the same org, those little technical choices turn into political ones 👀 bestie, this spec is going to be honest about that and spell out the political consequences of its design choices 💅
Okay, so transcripts are really about the student 🎀 The whole process exists because a student needs to prove their own achievements for jobs, college, scholarships, or whatever other reward is coming. So student needs should basically drive the design of a shared transcript exchange system 💖 A transcript proves personal merit, so students need documents that recipients will trust, meaning the origin and integrity of the content has to be guaranteed 🔥 A transcript also holds personal info about one student, so privacy is everything 🫶 The student has to be the one controlling who gets their transcript, and each student has to be able to keep their transcript confidential while it's moving around.
Communication between the originator, the student, and the final recipient is only really secure if it's end-to-end 🦋 The end-to-end argument [Sal84] is basically foundational to how the Internet is built, and it matters just as much for secure protocols (see Section 6.2 of RFC 1958 [RFC1958]). Meanwhile, securely sending student info to some centralized third party who isn't involved at all makes privacy worse and costs more 💀 Anyone claiming otherwise is either logically wrong or has a sketchy motive, ngl 🙈
Next up are the recipients 🍓 These could be college admissions officers, future employers, or scholarship foundations, and they need to be able to check the origin and integrity of a transcript easily and on their own 🌈 It's also a bonus if they can automatically pull out and summarize the content to feed into their own decision-making 🧚
Last but definitely not least is the originator, usually a high school guidance counselor or some other school official 💜 The originator wants to spend less money making transcripts and to meet any legal or moral duty to protect student privacy ⭐ Once transcripts are being made by computers, the big cost savings over manual processes come along for free, which is so iconic 👑 And the easiest, cheapest way for an originator to protect student privacy is to just not share a student's transcript info with anyone except that student 😭
A protocol where students have to formally request transcript deliveries doesn't actually help the student at all 🙄 It only serves the legal needs of third parties who want to get involved in what's supposed to be a private exchange 🚫 Formal requests only make sense when a middleman is in the picture, since in lots of places sharing personal info with a third party needs the student's consent, and an electronic request can reasonably be treated as implicit consent ✨ A formal request-response protocol also isn't needed to confirm a transcript reached its intended recipient 💖 When the student sends their own transcript directly to a recipient they picked, they care the most about it arriving, they can see any failures right away, and they can fix things if they need to 🎀 Familiar, standardized protocols give the student clear feedback on whether delivery worked 🫶 SMTP is the big one here, since it's designed 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
the message (see Section 6.1). Errors that are diagnosed
subsequently MUST be reported in a mail message, as discussed in
Section 4.4.SMTP's own spec is basically saying the receiver has to answer OK or failure, and once it says OK it owns the message 💅
3. Protocol Overview
Existing standardized tech makes preparing and sending secondary school transcripts so much easier 🌸 Using a computer, a school administrator makes a digital transcript that records one particular student's achievements and hands it to that student 🦋 The student then sends digital copies to whichever recipients they choose, using postal mail, secure email, or some other method 💌 Each recipient can use a computer to check that the transcript wasn't forged or changed in transit ✨ And since the transcript is digital, recipients can use computers to pull out and summarize the content for their own review and processing 🧚
Preparing and delivering a secondary school transcript involves three kinds of participant, and each one has its own job: the transcript originator, the student, and the transcript recipient 👑 The way each kind of participant interacts with the others is proscribed below 💀
3.1. Student and Originator
A transcript originator puts together and digitally signs academic transcripts that document individual students' achievements at a secondary school 🎀 This role is usually filled by the head of a high school guidance department or some other school official 💖 At fixed points during the school year, the guidance director runs a computer program that uses current info from a student database, and that program automatically makes an individual transcript report for each relevant student and digitally signs it on the director's behalf 🔥 The format of each signed transcript is defined in Section 5 below 🫶
The main responsibilities of a transcript originator are:
- Generate an OpenPGP key pair that can be used to sign school transcripts. 🔑
- Create and securely store a key revocation certificate for the signing key pair for possible future use should it be compromised. 🛡️
- Publish on the World Wide Web the public component of the transcript signing key pair, together with its OpenPGP fingerprint. 🌐
- 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. 🤫
- Use the signing key pair to create and digitally sign transcripts for individual students. ✍️
- Present each signed transcript confidentially to the individual student to which it pertains. 🎁
Once the originator makes a transcript, it gets to the right student by any means that keeps individual student data confidential 🦋 For example, a digital transcript can be saved to a CD-ROM and handed to the student when they come into school 💿 Or that same CD-ROM can be sealed in an envelope and mailed to the student 💌 A student could also bring a USB flash drive into the guidance office in person, and the digital transcript could be copied onto it 🧚 Another option is to attach the digital transcript as a MIME attachment to an email that is encrypted according to the OpenPGP specification 🔐 When email is used to send transcripts to students, formatting those messages as specified in Section 6 below will help with security and interoperability 💜
After a student gets their transcript from the originator, that student is solely responsible for sending it to any recipients they want, as described in Section 3.2 below 👑✨
3.1.1. Transcript Requests 🎀
okay so how students ask for a transcript from their secondary school is a local matter, and it honestly need not and ought not be addressed here 💅. there are a few reasons, bestie:
First, requests are probably gonna be pretty rare 🌸 because transcripts can be pre-issued to most students (like graduating seniors) who will need them. once a transcript is digital and the student can copy it easily, there's no reason to make a brand new document for every single recipient. so most transcript generation is driven by content updates from marking periods or academic sessions passing through the school year, not by student requests. explicit requests are the exception, not the rule ✨. think students who lost a transcript they already got, or students leaving before graduation.
Second, a big historical reason for formal transcript requests is that schools have a legal duty to protect student privacy 🔒. in lots of legal jurisdictions, school officials have to get the student's authorization before releasing information to a third party, and those elaborate request procedures are basically trying to codify or automate that step 🙄. BUT under the procedure defined here, each student's information is only given to that student, so no authorization for releasing information to a third party is needed 🔥.
Third, a codified transcript request protocol gives almost no benefit beyond letting third-party processors take on the role of transcript originator and/or distributor 💀. students don't need a formal "acknowledgment" of their requests, because the transcript itself is the acknowledgment ✨. a digital transcript is easily generated by an automated procedure, so returning an acknowledgment instead of the actual document has no benefit. the main goal of this protocol design is to strengthen student privacy and agency by cutting out third-party intrusion into what would otherwise be private, one-on-one interactions between a student and their school 🫶. codifying transcript requests would directly undercut that goal while restricting local student-school interactions for no good reason.
when each student, rather than a school official or middleman, has principal control over distributing their own transcript information, the need for transcript requests is mostly obviated 🦋. so exchanging and processing those requests is properly a local matter and not further addressed here.
3.2. Student and Recipient 🌈
when a student is asked (for example, by a college admissions office or a prospective employer) to provide an official transcript of their academic achievements, that student may send the requesting party a copy of the digitally signed transcript document they previously received from their secondary school 📄. in this context, the party asking the student to send a transcript is called a transcript recipient. because the student is the one conveying their own transcript information, they unambiguously control the set of recipients. neither the secondary school nor any third party is responsible for or privy to the identities of their correspondents 👑. similarly, the student is responsible for keeping their personal information private as they convey it to these recipients 🔐.
the student may convey their transcript to their chosen recipient using any mutually agreeable strategy. for example, they could print a copy of the transcript onto a postcard and send it through postal delivery 📮. this strategy doesn't strongly protect the confidentiality of the student's information in transit, and it doesn't let the recipient automate verification or other processing of the received transcript information 😬. sending a paper transcript sealed in a postal envelope better protects confidentiality, but it similarly restricts the recipient's ability to verify or process the transcript contents 💌. by copying the 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 their secondary school simply 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 themselves to their intended recipient (for example, if student and recipient are connected by a common, private network), then the student could send the transcript in a plaintext email. otherwise, the student SHOULD encrypt the email contents to protect their privacy during transmission 🔏.
if a student chooses to convey their school transcript to a transcript recipient via electronic mail, then the principal responsibilities of that student are:
- Create a personal email account and associated email address from which transmissions of the student's signed school transcript may be sent. ✨
- 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. 🔍
- Import the OpenPGP public key for each chosen recipient into the local OpenPGP key database. 🗝️
- 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 specified in Section 5 and the use of the transmission formats specified in Section 6 afford privacy and autonomy to students. by using these formats, recipients can independently verify the origin and integrity of the transcript information students provide 🦋. a common transcript representation also lets recipients automate the storage, analysis, and review of received transcripts 🤖.
however, a student can't use the format specified here to convey their transcript to a chosen recipient unless that recipient is ready to take part in the exchange 🙈. the principal responsibilities of a transcript recipient are:
- Generate an OpenPGP key pair that can be used to encrypt student transmissions of signed school transcripts to the recipient. 🔑
- 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. 🛟
- Create a (preferably dedicated) email address and mailbox to which students may direct transmissions of signed school transcripts. 📬
- 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. 🌐
- 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. 🛡️
- Assemble a collection of public OpenPGP keys published by legitimate transcript originators. 📚
- Receive and decrypt transcripts transmitted by students. 💜
- 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 means transcript recipients can 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 save the various transcript components locally for later review or processing 🌟.
using familiar email client applications to receive and review small numbers of school transcripts doesn't rule out more automated systems for university admissions departments or large employers 🏫. larger-volume recipients might ask students to direct their school transcripts to a particular email mailbox. transcripts delivered that way could be received, validated, and otherwise organized periodically by specialized application software 🤓. information in the computational component of received transcripts might be fed into a candidate database to make quantitative evaluations of the applicant pool way easier 📊✨.
4. Transcript Content ✨
okay so this is where the transcript actually gets built, bestie 🎀 A school transcript is one single MIME body part with the content type multipart/mixed. Inside that wrapper you get three separate MIME elements, in this order: a preface from the transcript originator about how to check and read the transcript (that's Section 4.1), a version made for computers to process automatically (Section 4.2), and a version made for humans to read and review (Section 4.3). Figure 3 is a little diagram of the whole structure, and Figure 4 shows what a real one looks like 💅
Every representation of transcript content MUST include exactly the following set of MIME content headers 🧚
Content-Type: this one comes from Section 5 of the MIME format specification [RFC2045]. When it's attached to the content of a signed school transcript, it MUST have the valuemultipart/mixed💜Content-Description: this one comes from Section 8 of [RFC2045] too. Its value gives humans "descriptive information" about the transcript. RFC 2045 says a content description header is optional, but here it is NOT optional. It MUST be included in the MIME representation of school transcript content 🙈MIME-Version: this one comes from Section 4 of [RFC2045] and tells you which version of the MIME spec the body part follows. Right now the value MUST always be1.0. Sometimes the EESST spec wants aMIME-Versionheader even when MIME alone wouldn't require one. These extra headers are on purpose, because they help people whose email clients aren't that capable keep nesting and displaying the transcript without getting lost 🦋Eesst-Version: this tells you which version of the EESST format the transcript follows. Right now the value MUST always be1.0✨From: this names the originator of the transcript. It includes the originating official's name and title, plus the identity of the OpenPGP key used to digitally sign the transcript, wrapped in angle brackets 🔐Organization: this names the organization or institution the originator belongs to. Inside a transcript, it names the secondary school that issued it. By convention, it includes the originating institution's name along with where it is located 🌸Subject: this one is optional, but if you include it, its value MUST match theContent-Descriptionheader. It gives humans "descriptive information" about what the transcript is about, and it helps some email readers show transcript emails more nicely 🍓Date: this is the date the transcript was created, and its format MUST be consistent with Section 3.3 of the email message specification [RFC5322] 🌈
Apart from the optional Subject header, every header listed above must appear in the MIME body part that holds the whole transcript. No other headers are allowed, and the allowed headers can show up in any order. Figure 4 has example headers, and in that figure "PESC" stands for the Postsecondary Electronic Standards Council (more on that in Section 4.2) 🎀
+--------------------------------------------------+
| TRANSCRIPT CONTENT |
| Content-Type: multipart/mixed |
| |
| +-------------------------------------------+ |
| | TRANSCRIPT PREFACE | |
| | Content-Type: text/plain | |
| | | |
| | Body represents transcript preface | |
| +-------------------------------------------+ |
| |
| +-------------------------------------------+ |
| | COMPUTATIONAL TRANSCRIPT | |
| | Content-Type: application/xml | |
| | | |
| | Body represents PESC XML computational | |
| | transcript | |
| +-------------------------------------------+ |
| |
| +-------------------------------------------+ |
| | DISPLAY TRANSCRIPT | |
| | Content-Type: application/pdf | |
| | | |
| | Body represents PDF display transcript | |
| +-------------------------------------------+ |
+--------------------------------------------------+Figure 3: MIME Structure of Transcript Content
Content-Type: multipart/mixed; boundary="===============BBBBBBBBBB=="
MIME-Version: 1.0
Content-Description: Official School Transcript for Hermione Granger
Subject: Official School Transcript for Hermione Granger
From: Transcript Authority at Hogwarts School
<transcript-authority@hogwarts.edu.example>
Organization: Hogwarts School for Witchcraft and Wizardry
Eesst-Version: 1.0
Date: Fri, 22 Mar 2013 09:55:06 -0600
--===============BBBBBBBBBB==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="preface.txt"
Content-Description: School Transcript Preface
To Whom It May Concern:
This academic transcript describes the accomplishments of an
...
--===============BBBBBBBBBB==
Content-Type: application/xml
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="transcript.xml"
Content-Description: School Transcript rendered as PESC XML
<HSTrn:HighSchoolTranscript=20xmlns:AcRec=3D"urn:org:pesc:sector:Acad
...
cord></Student></HSTrn:HighSchoolTranscript>
--===============BBBBBBBBBB==
Content-Type: application/pdf
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="transcript.pdf"
Content-Description: School Transcript rendered as PDF
JVBERi0xLjMNCiWTjIueIFJlcG9ydExhYiBHZW5lcmF0ZWQgUERGIGRvY3VtZW50IGh0d
...
IC9Sb290IDEwIDAgUg0KIC9TaXplIDE2ID4+DQpzdGFydHhyZWYNCjE3OTIzDQolJUVPR
--===============BBBBBBBBBB==Figure 4: Example Transcript Content
4.1. School Transcript Preface
okay this is the friendly cover letter 💌 A school transcript preface is generic commentary from the school official, written so that any human can read it without special apps. It SHOULD be generic, covering how the issuing school prepares and reads its transcripts. It SHOULD NOT include information about any one student 🙅♀️ Think of it like a letter addressed to whoever ends up with the transcript. It could explain how to check the digital signature, or why the school's grading is a bit unusual 🧐 A preface is represented as a MIME body part whose content type is text/plain ✨
Heads up: when a transcript gets packed inside a bigger email, random text in the preface could accidentally look like MIME boundaries or email headers. The risk goes down if the preface avoids lines that start with a hyphen (-), lines that start with an angle bracket (>), or the word "From." 😬
Ideally the preface is totally readable without help, but if those characters can't be avoided, transcript originators SHOULD apply a content transfer encoding to the preface. That keeps the intermediary mail transfer agents from misreading it 🫶
The preface SHOULD NOT include any header fields beyond the ones listed in the specification for MIME message bodies [RFC2045] 🌸
More parts are coming, so keep your eyes peeled for Section 4.2! 🦋
4.2. Computational School Transcript 🤖💻
okay so a computational school transcript is the version of someone's academic accomplishments that's built for machines to read ✨ It's written in Extensible Markup Language (XML) [XML11] and sent as a MIME body part whose content type is "application/xml". The syntax of the data MUST conform to the XML schema for High School Transcripts, Version 1.3.0 [Fun12b], published by the Postsecondary Electronic Standards Council (PESC). That schema depends on the Academic Record XML schema, Version 1.7.0 [Fun12a], and the Core Main XML schema, Version 1.2.0 [Mar06], also published by PESC. The detailed meaning of the data elements lives in the PESC XML implementation guide, Version 1.3.0 [Ste12], which also has usage examples 📚
protecting student privacy is super important 🔒 so this spec doesn't force a transcript to include any particular student info. It just defines a common format for whatever info gets shared voluntarily between consenting parties. What gets shared is totally a local matter, and a transcript originator MAY omit from transcript content any info (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 seen locally as sensitive or irrelevant. Honestly, the PESC schema barely limits what the originator chooses to include. Figure 5 shows a minimal set of XML elements that meets the syntax rules, and a computational transcript doesn't need to say more about a student than what that figure shows 🫶
to stop anyone from quietly monitoring or controlling who a student shows their transcript to, this spec restricts some uses of the PESC schema 👀 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 is what lets a student use self-made copies of a signed transcript for whatever they want without checking with school officials 💅 If the originator could stamp specific destinations onto each copy, they could track and kinda control which college admissions officers, prospective employers, or other third parties get it. Transcript recipients MUST reject any transcript whose content in any way specifies or restricts the audience, recipient, or distribution for that transcript. Even with that restriction on the "Destination" element, the "Source" element SHOULD be included and convey info that's enough to identify the secondary school or other institution that issued the transcript 🏫
<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
there are also some extra rules for using the PESC XML schema, so that computational transcripts are read the same way everywhere and are easy to process 🧠
- To meet the minimal syntax rules of the PESC XML schema, every computational transcript MUST include at least the XML elements that appear in Figure 5. Even when an originator wants to convey no information, the computational transcript must still be included in the transcript content, and its payload must have the form shown in Figure 5 🌸
- Consistent with the PESC XML schema, any value given to the "DocumentID" XML element must be at least one non-whitespace character long 🔢
- Consistent with the PESC XML schema, any value given 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] ⏰
- Lest the origin and correct handling for a computational transcript be misunderstood, the value given to the "DocumentTypeCode" XML element MUST be "StudentRequest" 🙈
- Lest the origin and correct handling for a computational transcript be misunderstood, the value given to the "TransmissionType" XML element MUST be "MutuallyDefined" 🙈
- Apart from the XML elements that appear in Figure 5, info that isn't provided in a computational transcript MUST be represented by entirely omitting the relevant XML data element. Omitted info MUST NOT be represented by including an XML element whose textual value is zero length or contains only whitespace 🫧
The representation of a computational transcript SHOULD NOT include any header fields beyond those listed 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 is the human-friendly version 👩🎓 It describes the academic accomplishments of an individual student in a form that people can read and review. It's represented as a MIME body part whose content type is "application/pdf", and its content conforms to the Portable Document Format (PDF) specification [PDF17]. A display school transcript may take up one or more physical pages 📄
to lower the chance that the recipient of a signed school transcript misreads it, the computational component (described in Section 4.2 above) and the display component (defined here) of each signed school transcript SHOULD convey, as much as possible, identical info about the student's academic accomplishments 👯♀️
Nothing in this specification should be read as requiring the use of digital signature features embedded in individual PDF documents under the PDF specification. Instead, the data integrity and origin identity of all components in a school transcript --- including the PDF display transcript --- are already well protected by the OpenPGP signature of the transcript originator, which this specification requires. So implementing PDF-specific signature features is optional and honestly largely unnecessary. Transcript recipients MUST accept transcripts that include PDF signatures, but they SHOULD neither verify nor depend on 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 already protect the confidentiality of student info in transit, so encrypting the display transcript separately is redundant. Double encryption adds implementation complexity and also raises 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 that come up when using PDF as a MIME media type 😱 One of them is that PDF documents may include executable "scripts" or references to external, executable plug-in modules. Including arbitrary executable programs (or references to them) in a PDF transcript document poses a security risk to transcript recipients. Digitally signing PDF documents (or even the transcripts that contain them) doesn't help recipients judge whether it's safe to run any embedded programs or plug-ins. The main job of PDF here is to show static transcript info in a pretty format for humans to look at. Because that limited purpose is served just fine without embedded executable elements, any risk from including them isn't worth it. So transcript originators MUST NOT include any executable scripts or external plug-in references in a PDF display transcript. To avoid running 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 listed in the specification for the format of MIME message bodies [RFC2045] 🌷
5. Signed School Transcript ✨
okay so a signed school transcript is a MIME body part that's built like a signed OpenPGP/MIME message 🎀 (see section 5 of the OpenPGP/MIME spec [RFC3156]). Its content type is multipart/signed, which is the classic multipart MIME trick for locking down email [RFC1847]. So the body has exactly two parts, shown in Figure 6 💅
The first part carries the transcript content in MIME canonical format, with an appropriate set of MIME content headers. How that content is formed and read is covered in Section 4 above 📚 The second part is the school transcript signature 🔐 It's the OpenPGP digital signature from the transcript originator, applied to the content in that first part. This signature gets the content type application/pgp-signature. And ya, transcript recipients MUST reject any transcript that isn't validly signed under the OpenPGP signature spec [RFC3156]. no exceptions bestie 🙅♀️
+--------------------------------------------------+
| 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
Now the headers 🎀 Every MIME content header on a signed transcript MUST match the embedded transcript content exactly, with one tiny exception: the Content-Type header, which is allowed to be different. For a signed transcript, Content-Type MUST be multipart/signed, its parameters MUST follow section 5 of the MIME/OpenPGP spec [RFC3156], and the boundary value shall, of course, be different from every other boundary value in the same message. Figure 7 shows example headers so you can see the vibe ✨ The headers can show up in any order, but transcript recipients MUST reject any signed transcript whose set of included headers isn't the same as the set on the embedded transcript content. the order is flexible, the set is not 🙈
Content-Type: multipart/signed;
protocol="application/pgp-signature";
micalg="pgp-sha256";
boundary="===============AAAAAAAAAA=="
MIME-Version: 1.0
Content-Description: Official School Transcript for Hermione Granger
Subject: Official School Transcript for Hermione Granger
From: Transcript Authority at Hogwarts School
<transcript-authority@hogwarts.edu.example>
Organization: Hogwarts School for Witchcraft and Wizardry
Eesst-Version: 1.0
Date: Fri, 22 Mar 2013 09:55:06 -0600
--===============AAAAAAAAAA==
Content-Type: multipart/mixed; boundary="===============BBBBBBBBBB=="
MIME-Version: 1.0
Content-Description: Official School Transcript for Hermione Granger
... Transcript Content as illustrated in Figure 4 ...
--===============BBBBBBBBBB==--
--===============AAAAAAAAAA==
Content-Type: application/pgp-signature; name="signature.asc"
MIME-Version: 1.0
Content-Description: OpenPGP signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQEcBAABAgAGBQJRmkkLAAoJEBzD54azv/d4j4gH/1Aj8poEHLsEhxdv26H76URX
...
8/SQRZGUGUC0xSej5uQMVI59Yriy3dedlzib7EadK6fnz70SsEzUcQy5lHFkNNA=
=8QLW
-----END PGP SIGNATURE-----
--===============AAAAAAAAAA==--Figure 7: Example Signed School Transcript
The Eesst-Version header is the secret MVP 🦋 Like, it's not obvious at first, but it's crucial for anyone implementing this. Its presence unambiguously tells you a signed school transcript apart from the enveloping email message that might be carrying it around 👀
It's not an accident that the format here looks so much like a standard OpenPGP/MIME message [RFC3156] 💜 That similarity is a huge win: recipient code can reuse stuff, and most importantly, transcript recipients can inspect, verify, and pull out received transcripts using email clients that are already everywhere 📬
The catch? Those shared looks can get messy for recipient implementations 😭 A signed transcript and the email message carrying it both have the typemultipart/signedand both have exactly two MIME body parts, one for the signed content and one for the signature. So when amultipart/signedpart shows up in an email, is it a proper signed school transcript, a signed email that's delivering a transcript, an ill-formed transcript, or something else entirely? Without extra info, you can only answer that by fully verifying, parsing, validating, and checking every signed body part, because the receiver can't know which tests to run in advance. Wild, right? 🙃
That's why Eesst-Version does at least two jobs 🧚 The obvious one is saying which version of the EESST format was used to prepare the transcript. Right now, the only acceptable version is 1.0 💅 but refusing to leave room for future evolution is literally ignoring history, and nobody wants that energy. The less obvious job is that it gives you simple, unambiguous detection of signed school transcripts, while still letting recipients validate and review them with familiar, widely available email clients 🌈
So, final verdict: Eesst-Version MUST be included in signed school transcripts and in their content component 🫶 But to really get the most out of it as a syntactic disambiguator, Eesst-Version MUST NOT appear anywhere else. Keep it exclusive, keep it iconic ✨
6. Transcript Transmission ✨
okay so the big idea here is that the student is the boss of their own transcript 👑. As long as the transcript originator is not allowed to disclose personal information without student consent, the EESST protocol lets each student decide who gets their transcript, and only the people they pick 💖. The design doesn't just keep the transcript content private while it's traveling. It also makes it way harder for the school or anyone else to keep tabs on a student's chats with colleges, prospective employers, or other third parties 🙈.
A student can send their signed school transcript to their chosen recipient using literally any medium or tech that both of them are cool with 🦋. For example, they could burn their signed digital transcript onto a CD-ROM and mail the disk through the postal service 💀. But email is gonna be the most convenient option for most students, so this spec defines a common email format that lets each student privately send their signed school transcript to each recipient 📬. Having one common format makes transcript transmission simpler to implement and helps different implementations work together 🫶. It also lets high-volume recipients automate decryption, validation, and prep for review and analysis 🔥. And because the format is built on existing email standards, low-volume recipients can use popular email client software to receive, decrypt, validate, and review transcripts 💅.
When a student sends their transcript by email, their confidential info is vulnerable to interception and disclosure 😭. To deal with that, this spec generally requires the email message to 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 the traditional inline transmission format (Section 6.4) below. These latter formats make it easier to use a more trusted computer to encrypt a student's transcript, and then move the encrypted version to a less trusted computer for sending to the chosen recipient 🧚.
Because transcript transmissions must be encrypted to protect student privacy, every potential transcript recipient MUST generate an OpenPGP key pair and publish its public component so students can use it when preparing transmissions 🔑. The public key for each transcript recipient should be published (together with its OpenPGP fingerprint) on that recipient's web page or in the global OpenPGP key database 🌸. To protect the privacy of the personal info sent to each chosen recipient, a student only needs to grab that recipient's published key and use it to encrypt the transmission 🎀.
Now, with some effort, an attacker could pretend to be a legit transcript recipient and maybe trick a student into sending private info to the attacker, encrypted with a key the attacker knows 👀. To protect student privacy against that, a transcript recipient should resist forgery of their OpenPGP identity by asking other trustworthy people (like respected colleagues or institutional officers) to certify that identity 🛡️. An OpenPGP identity gets certified when someone else puts their digital signature on the associated OpenPGP key (see Section 12 of the OpenPGP message format specification [RFC4880] and Section 3 in the GNU Privacy Handbook [GPH]). Anyone who signs a recipient's public key is basically vouching that the key really belongs to the true identity of the recipient 🫶. Since the student carries the main responsibility for their transcript's privacy, the student is ultimately the one who has to evaluate whether the public keys they use to encrypt that info in transit are authentic 💜. Adding certifying signatures to a recipient's key lowers the chance that a student gets fooled by an imposter ✨.
Here's the big structural move: this protocol sharply separates transcript creation from transcript transmission, so student privacy and autonomy get maximized 👑. Creation belongs exclusively to the issuing secondary school (the transcript originator), and transmission belongs exclusively to the individual student. Everyone in the protocol has to act in a way that keeps that separation intact 🦋. A transcript originator MUST NOT transmit, share, or distribute a school transcript or any component of it to any party other than the individual student it belongs to. A transcript recipient MUST reject any transcript that seems to have been transmitted by or on behalf of anyone other than the student. Non-student transmission can be hard to detect reliably, but certain transmission characteristics clearly suggest someone is abusing student prerogatives 🚨. So all recipient implementations MUST detect and reject transcript transmissions with any of the following characteristics:
- 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.
- A transcript recipient MUST reject any transcript for which the transcript originator and the sender of the transcript transmission are identical.
- 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.
- A transcript recipient MUST reject any transcript for which the received transcript transmission is addressed to multiple recipients.
6.1. Encrypted Format
okay so in the encrypted transmission format, the signed school transcript goes to one single recipient as a MIME attachment on an OpenPGP encrypted email message 🎀. Following Section 4 of the OpenPGP/MIME specification [RFC3156], the email must have the MIME content type "multipart/encrypted", and the body must have exactly two parts, like in Figure 8 🌈. The first body part must have the MIME content type "application/pgp-encrypted", and its content must contain only the literal value Version: 1 on a line by itself. The second body part must have the MIME content type "application/octet-stream". Its content is the result of running the OpenPGP encryption algorithm on 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 📊
6.2. Encrypted and Signed Format 🎀
Okay so the encrypted and signed format sends the signed school transcript to a single recipient as an attachment on an OpenPGP encrypted and signed email 💌. Following Section 6.1 of the OpenPGP/MIME specification [RFC3156], building one of these is a two-stage process 🔥. First, the transcript transmission gets digitally signed by the student sending it ✍️. Then it gets encrypted, so the student's info can't be disclosed to anyone except 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 is applying the student's signature to the transmission content ✨. As shown in Figure 9, the resulting MIME body part has content type multipart/signed and is made of exactly two parts. Part one is the signed transmission content, which matches the signed school transcript in its entirety. Its structure is shown in Figure 6. Part two is the transmission signature, with MIME content type application/pgp-signature. Its content is the result of running the OpenPGP signature algorithm, using the student's private key, over the transmission content. That's the canonical representation of the signed school transcript, and the transcript originator has already signed it 🫶.
+--------------------------------------------------+
| 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 is wrapping the stage-one result in an OpenPGP encrypted message, which keeps student info away from anyone but the lone recipient 🌸. As shown in Figure 10, the encrypted transcript transmission has the form proscribed in Section 6.1 of the OpenPGP/MIME specification. Its 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 💅.
6.3. Encrypted File Format 🔐
Okay, real talk, the privacy protections in the EESST protocol only work if the student's computer does its EESST job properly without leaking any confidential info 😭. Specifically, the transmitting computer has to stop anyone except the student from getting at the plaintext of a school transcript. Its hardware and software also has to be free of any flaws that could weaken the encryption on the transcript. And it has to send the transcript reliably and directly to each chosen recipient, without telling any third party either that the transmission happened or who the recipient is 👀. Checking all of this can be really tricky when the student doesn't fully own and control the computer they're using 🙈.
Sometimes the computer a student has to send from just can't be trusted 💀. Some email client implementations straight up don't let students write a secure email without sharing private info with their email provider, system administrator, or some other third party. Web-based email clients are probably the most obvious and widespread example of an email platform that's insecure by nature: neither cryptographic keys nor plaintext message content can be stored or processed safely on them 🙅♀️. Another insecure platform is the computers and email servers schools provide for student use, since school administrators and technical staff, as a practical matter, have unrestricted access to them 🏫.
A student can use the encrypted file transmission format when the computer they have to send from can't be trusted to do the encryption correctly, or without disclosing the plaintext transcript. This format makes it easier to use a more trusted computer for the encryption, and then move the encrypted version over to a less trusted computer for sending to the chosen recipient 🦋.
Here's an example ✨. The student can use an OpenPGP implementation on a trusted computer to encrypt the plaintext version of their signed school transcript, which they got from the transcript originator. The key for this encryption is the public OpenPGP key of the intended transcript recipient. The binary file that comes out of this encryption is then moved (for example, on a USB flash drive or through a networked file transfer protocol) to a less trusted computer for email sending. On that less trusted computer, the student opens an email client to compose and send a plaintext email message to the recipient (see Figure 11 for an example). The message is formatted according to the MIME specification [RFC2045]. The binary file with the encrypted transcript goes in the message as a MIME attachment whose content type is application/octet-stream 💜.
When the recipient gets the email, the MIME attachment holding the encrypted school transcript may be detached and saved as a binary file on the local disk. A local OpenPGP implementation is run to decrypt the saved file, using the private OpenPGP encryption key the transcript recipient generated 🧚. Large-volume transcript recipients may automate the process of detaching and decrypting the attached school transcript 🤖.
Message-ID: <55650A7F.7090800@granger-dentistry.com.example>
Date: Tue, 26 May 2015 20:06:23 -0400
From: Hermione Granger <hermione@granger-dentistry.com.example>
MIME-Version: 1.0
To: Dean Vernon Wormer <transcript-receiver@faber.edu.example>
Subject: Transmission of School Transcript
Content-Type: multipart/mixed;
boundary="------------010307000006020005010307"
This is a multi-part message in MIME format.
--------------010307000006020005010307
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Dear Dean Wormer:
Please find attached my high school transcript, encrypted in the
public encryption key published by Faber College for transcript
transmission. I stored the plaintext signed transcript that I
received from my high school on my own secure computer under the
filename TrnGranger.eml and encrypted its contents for transmission
by invoking the following command:
gpg --encrypt --recipient transcript-receiver@faber.edu TrnGranger.eml
The resulting encrypted file, TrnGranger.eml.gpg, is attached to
this email message. Save that file to the disk on your local
computer and decrypt the transcript by invoking the command:
gpg --output TrnGranger.eml --decrypt TrnGranger.eml.gpg
Sincerely,
Hermione Granger
--------------010307000006020005010307
Content-Type: application/octet-stream; name="TrnGranger.eml.gpg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="TrnGranger.eml.gpg"
hQEMA4Fu2Js7ulkaAQf/aeiLeoy9L+YddGr0HieHd3KH3wiqLnaImsBaLfboGx+EdTIRn
...
cSJlVDOZKj6nPULT5zqYsfTEHPf+5escZab4J2Rkt/w1BhNDtulNJrbv6q2lk3xBzlt+Z
kQ==
--------------010307000006020005010307--Figure 11: Encrypted File Transcript Transmission
6.4. Traditional Inline Format ✨
okay so bestie, this one's for the student whose computer is kinda sus 💀. A student can use the traditional inline transmission format when the computer they have to send from can't be trusted to do the encryption properly, or can't be trusted not to expose the plaintext transcript 🙈. Just like the encrypted file format from Section 6.3, the inline format lets you encrypt on a more trusted computer and then carry the encrypted version over to a less trusted machine for sending to the recipient 🧚
The inline format lets a student use an OpenPGP implementation on a trusted computer to encrypt the plaintext version of their signed school transcript, the one they got from the transcript originator 🎀. The key used for that encryption is the intended transcript recipient's public OpenPGP key 🔑. The encrypted transcript is stored as an ASCII-armored text file, which gets moved (for example by USB flash drive or a networked file transfer protocol) to the less trusted computer for email sending 💌. On that computer, the student opens an email client to write and send a plaintext email to the recipient. The contents of the ASCII-armored file are then pasted (or otherwise inserted) into the new message as the only thing in the body 💅
A traditional inline transcript transmission is just a simple email message (in the Internet Message Format [RFC5322]) whose body is nothing but the encrypted form of the signed school transcript being sent 🦋. 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. Here's an example inline transcript transmission, shown in Figure 12 ✨
Return-Path: <hermione@granger-dentistry.com.example>
Delivered-To: transcript-receiver@faber.edu.example
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain
Date: Wed, 3 Jul 2013 12:40:01 -0400
From: Hermione Granger <hermione@granger-dentistry.com.example>
To: Transcript Receiver at Faber College
<transcript-receiver@faber.edu.example>
Subject: Encrypted Inline Transmission of School Transcript
X-Mailer: smtp-cli 3.3, see http://smtp-cli.logix.cz
Content-Transfer-Encoding: 8bit
Message-ID: <1372869801.14441.1.camel@hermione>
-----BEGIN PGP MESSAGE-----
Version: GnuPG v1.4.10 (GNU/Linux)
hQEMA4Fu2Js7ulkaAQf9Fm4+75kE6gQ1T8pjzf4GJhtBqxTTh2AaGtKZkZy9TW8h
zsbSNzZuTVf8QvJRSfk0mZywRG42dilf4Zoygpj3xJgKf7JlCEXnY5m4Luq5hvnW
...
hKgY5Kye/cu/4qwYdFOiljkMR1tv1Avh37OmmcMOZ6Hy9gbdrgQzHsPVWLDQNUYy
jxUAN8thZooRj/jHgq23EZaNyKxD
=Dga7
-----END PGP MESSAGE----- Figure 12: Traditional Inline Signed Transcript TransmissionWhen the recipient gets the email, their local OpenPGP implementation gets invoked to pull out the inline encrypted transcript and decrypt it, using the private OpenPGP encryption key the recipient generated 🔐. Large-volume recipients may automate the process of extracting and decrypting the transmitted school transcript 🤖
Real talk: the traditional inline format is an acceptable way to send a secure transcript 💖, but it's probably best for students who don't have any ready alternatives 🥺. Inline OpenPGP representation can sometimes clash with other email features and conventions, so the encrypted file format may be the better move when the sending computer can't be trusted 🧐. There's a brief essay by Josefsson [Jos07] that lays out several difficulties that can come up with inline OpenPGP. None of them is strictly relevant to a correctly formed EESST transcript transmission, but it's still good tea 🍵. So the traditional inline format may be used when needed, but only with full consideration of its potential limitations on interoperability ⚠️
7. Security Considerations 🔐
The security of the EESST protocol depends on the security of the OpenPGP protocols it's built on 🛡️ The cryptographic algorithms in OpenPGP are among the strongest used in any known protocol, but the integrity, authenticity, and confidentiality of the student information being conveyed is only assured if EESST protocol implementors and users faithfully observe all requirements and recommendations of the relevant specifications ([RFC4880], [RFC3156], and [RFC4270]). This part is serious, bestie 😭 In particular, the SHA-256 digest algorithm and RSA key lengths of at least 2048 bits MUST be used. The good news is that these are supported by all major OpenPGP implementations 🎉
7.1. Originator Private Key
The authority and integrity of generated school transcripts depend on the private cryptographic key used to sign them staying secret 🤫 For the 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 a transcript originator, a key revocation certificate should also be generated and stored securely 🗝️ If the generated key pair is ever compromised, the stored revocation certificate may be used to notify others to reject later 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 of 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 want to publish an online collection of OpenPGP public keys submitted by its members 🗂️ A college admissions officer (or other high-volume transcript recipient) could then download and import that key collection into a local key database for verifying received transcripts 🎓
7.3. Originator Certification
To reduce the chance that an imposter successfully pretends to be a particular transcript originator and swaps in 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. So 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 too 💜
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 of the receiving institution and/or in the global OpenPGP key database 📬
7.5. Secure Clients
The cryptographic operations this protocol's security depends on must be performed in private by the relevant stakeholder 🙅♀️ A student's personal transcript information can't stay confidential if others get unauthorized access to that content during encryption. The integrity of an originator's signature on each transcript can't be assured if others can learn the originator's secret key by watching the signing process 😱 And the confidentiality of personal information sent by many students to one transcript recipient can't be assured if others can learn that recipient's secret key by watching received transcripts get decrypted 💀
So every stakeholder should only perform the cryptographic operations proscribed here while physically present at a physically isolated computer that is entirely controlled by that stakeholder and that stores all keys and confidential information locally 🔒 Using "thin clients" or web-based computing for sensitive cryptographic operations gives up whatever protections this protocol might otherwise have provided 🫠
7.6. Automatic Replies
Recipient implementations should not reply automatically or routinely to received transcript transmissions 🤐 Such replies could give valuable feedback to an attacker, especially if they can be triggered at will 🕵️♀️
8. IANA Considerations 🌸
The EESST exchange format is compatible with existing email standards and entails no alterations to them 💯 The syntactic similarity between the exchange format and standardized email message formats is the best part, because users can apply widely deployed email tools to verify, interpret, or otherwise manipulate secondary school transcripts 🛠️
To help prevent any incompatibilities that could come from future standards evolution or changes in common usage, this section describes the registration of two message header fields. Both 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 🦄
8.1. Registration of Eesst-Version Header
The "Eesst-Version" message header field is completely internal to the EESST transcript format, and it is explicitly precluded from appearing within an enveloping email message (see Section 5) 🚫 Registration has been completed 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 uses the "Organization" message header field to identify the originating institution for a student transcript 🏛️ A header field with this name and semantics is already defined for use within network news articles (see [RFC5536]). The "Organization" header field also shows up a lot in electronic mail messages, although, perhaps surprisingly, it currently lacks any explicit, written definition in that context 🤯 This registration publicly documents the ongoing use of this header field and may discourage incompatible uses in the future 📣
Header field name: Organization
Applicable protocol: mail
Status: informational
Author/Change controller: James R. Davin
info@eesst.org
http://www.eesst.org
Specification document(s): RFC 7681
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
Okay bestie, the normative references are the ones you have to read to get this spec. 🎀 The big one is the BCP 14 key words document.
- [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
These are the extra reads that give you the background. Totally optional, but I'm obsessed with them. 🧚
- [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. 🍓 - [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. 📮 - [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%20Guide%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 ✨
Huge shoutout to Derek Atkins, Paul Hoffman, and Werner Koch, who gave independent reviews of this memo. 🫶 Fred Baker, Dave Crocker, Keith Moore, and Chris Newman also gave comments and questions on the drafts, and the document is so much better because of them. 💖
Author's Address
James R. Davin 🎀
Email: info@EESST.org URI: http://EESST.org/
📦 where this page comes from
- ietf: rfc7681 2015-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms