tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 7681

 
 
 

Email Exchange of Secondary School Transcripts

Part 2 of 2, p. 21 to 40
Prev RFC Part

 


prevText      Top      Up      ToC       Page 21 
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

Top      Up      ToC       Page 22 
   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.

Top      Up      ToC       Page 23 
   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

Top      Up      ToC       Page 24 
   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

Top      Up      ToC       Page 25 
   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

Top      Up      ToC       Page 26 
   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.

Top      Up      ToC       Page 27 
   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

Top      Up      ToC       Page 28 
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.

Top      Up      ToC       Page 29 
         +--------------------------------------------------+
         | 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.

Top      Up      ToC       Page 30 
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

Top      Up      ToC       Page 31 
   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.

Top      Up      ToC       Page 32 
  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

Top      Up      ToC       Page 33 
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

Top      Up      ToC       Page 34 
   conventions, the encrypted file format may be a better alternative
   for transcript transmissions when the transmitting computer cannot be
   trusted.  A brief essay by Josefsson [Jos07] identifies multiple
   difficulties that can arise from use of inline OpenPGP, although none
   is strictly relevant to a correctly formed EESST transcript
   transmission.  Accordingly, the traditional inline format may be used
   when needed but only with full consideration of its potential
   limitations on interoperability.

   Return-Path: <hermione@granger-dentistry.com.example>
   Delivered-To: transcript-receiver@faber.edu.example
   MIME-Version: 1.0
   Content-Disposition: inline
   Content-Type: text/plain
   Date: Wed, 3 Jul 2013 12:40:01 -0400
   From: Hermione Granger <hermione@granger-dentistry.com.example>
   To: Transcript Receiver at Faber College
      <transcript-receiver@faber.edu.example>
   Subject: Encrypted Inline Transmission of School Transcript
   X-Mailer: smtp-cli 3.3, see http://smtp-cli.logix.cz
   Content-Transfer-Encoding: 8bit
   Message-ID: <1372869801.14441.1.camel@hermione>

   -----BEGIN PGP MESSAGE-----
   Version: GnuPG v1.4.10 (GNU/Linux)

   hQEMA4Fu2Js7ulkaAQf9Fm4+75kE6gQ1T8pjzf4GJhtBqxTTh2AaGtKZkZy9TW8h
   zsbSNzZuTVf8QvJRSfk0mZywRG42dilf4Zoygpj3xJgKf7JlCEXnY5m4Luq5hvnW
       ...
   hKgY5Kye/cu/4qwYdFOiljkMR1tv1Avh37OmmcMOZ6Hy9gbdrgQzHsPVWLDQNUYy
   jxUAN8thZooRj/jHgq23EZaNyKxD
   =Dga7
   -----END PGP MESSAGE-----

       Figure 12: Traditional Inline Signed Transcript Transmission

7.  Security Considerations

   The security of the EESST protocol depends upon the security of the
   OpenPGP protocols on which it is based.  Although the cryptographic
   algorithms included in OpenPGP are among the strongest used in any
   known protocol, the integrity, authenticity, and confidentiality of
   conveyed student information is not assured unless EESST protocol
   implementors and users faithfully observe all requirements and
   recommendations of the relevant specifications ([RFC4880], [RFC3156],
   and [RFC4270]).  In particular, the SHA-256 digest algorithm and RSA
   key lengths of at least 2048 bits MUST be used.  Happily, these are
   supported by all major OpenPGP implementations.

Top      Up      ToC       Page 35 
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.

Top      Up      ToC       Page 36 
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.

Top      Up      ToC       Page 37 
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

Top      Up      ToC       Page 38 
   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>.

Top      Up      ToC       Page 39 
   [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>.

Top      Up      ToC       Page 40 
   [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/