RFC 7681
Email Exchange of Secondary School Transcripts
Pages: 40
Informational
Informational
Part 2 of 2 – Pages 21 to 40
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
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.
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha256"; boundary="===============AAAAAAAAAA==" MIME-Version: 1.0 Content-Description: Official School Transcript for Hermione Granger Subject: Official School Transcript for Hermione Granger From: Transcript Authority at Hogwarts School <transcript-authority@hogwarts.edu.example> Organization: Hogwarts School for Witchcraft and Wizardry Eesst-Version: 1.0 Date: Fri, 22 Mar 2013 09:55:06 -0600 --===============AAAAAAAAAA== Content-Type: multipart/mixed; boundary="===============BBBBBBBBBB==" MIME-Version: 1.0 Content-Description: Official School Transcript for Hermione Granger ... Transcript Content as illustrated in Figure 4 ... --===============BBBBBBBBBB==-- --===============AAAAAAAAAA== Content-Type: application/pgp-signature; name="signature.asc" MIME-Version: 1.0 Content-Description: OpenPGP signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAABAgAGBQJRmkkLAAoJEBzD54azv/d4j4gH/1Aj8poEHLsEhxdv26H76URX ... 8/SQRZGUGUC0xSej5uQMVI59Yriy3dedlzib7EadK6fnz70SsEzUcQy5lHFkNNA= =8QLW -----END PGP SIGNATURE----- --===============AAAAAAAAAA==-- Figure 7: Example Signed School Transcript The "Eesst-Version" header serves a crucial if non-obvious purpose for protocol implementors. The presence of this header unambiguously distinguishes a signed school transcript from elements of an enveloping email message by which that transcript may be conveyed. For good reason, the format defined here for signed school transcripts intentionally shares many characteristics with the standard format for OpenPGP/MIME messages [RFC3156]. This similarity
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
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
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.
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
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.
+--------------------------------------------------+ | 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.
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
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.
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
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
conventions, the encrypted file format may be a better alternative for transcript transmissions when the transmitting computer cannot be trusted. A brief essay by Josefsson [Jos07] identifies multiple difficulties that can arise from use of inline OpenPGP, although none is strictly relevant to a correctly formed EESST transcript transmission. Accordingly, the traditional inline format may be used when needed but only with full consideration of its potential limitations on interoperability. Return-Path: <hermione@granger-dentistry.com.example> Delivered-To: transcript-receiver@faber.edu.example MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain Date: Wed, 3 Jul 2013 12:40:01 -0400 From: Hermione Granger <hermione@granger-dentistry.com.example> To: Transcript Receiver at Faber College <transcript-receiver@faber.edu.example> Subject: Encrypted Inline Transmission of School Transcript X-Mailer: smtp-cli 3.3, see http://smtp-cli.logix.cz Content-Transfer-Encoding: 8bit Message-ID: <1372869801.14441.1.camel@hermione> -----BEGIN PGP MESSAGE----- Version: GnuPG v1.4.10 (GNU/Linux) hQEMA4Fu2Js7ulkaAQf9Fm4+75kE6gQ1T8pjzf4GJhtBqxTTh2AaGtKZkZy9TW8h zsbSNzZuTVf8QvJRSfk0mZywRG42dilf4Zoygpj3xJgKf7JlCEXnY5m4Luq5hvnW ... hKgY5Kye/cu/4qwYdFOiljkMR1tv1Avh37OmmcMOZ6Hy9gbdrgQzHsPVWLDQNUYy jxUAN8thZooRj/jHgq23EZaNyKxD =Dga7 -----END PGP MESSAGE----- Figure 12: Traditional Inline Signed Transcript Transmission7. 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.
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.
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.
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
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>.
[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%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/